ekrn.exe buffer overflow

wondering whether that justifies for some concern, the core AV component causing buffer overflows? perhaps time for a 64bit ekrn.exe?

W7 64bit / NOD 4.2.64.12 with DEV exe/dll

Virus signature database: 5591 (20101104)
Update module: 1031 (20091029)
Antivirus and antispyware scanner module: 1292 (2010102
Advanced heuristics module: 1114 (20100827)
Archive support module: 1122 (20100826)
Cleaner module: 1048 (20091123)
Anti-Stealth support module: 1022 (20100812)
SysInspector module: 1217 (20100907)
Self-defense support module : 1018 (20100812)
Real-time file system protection module: 1004 (20100727)

 

well, the silence by Eset is not much of a surprise, the product went past QA in this state.

yet it is to me that in an IT security forum covering a security product nobody is interested/willing/capable or whatever to discuss buffer overflows caused by the core of an AV product.

if on the other hand nobody is concerned then I would appreciate to know the reason and why one should not be bothered about buffer overflows

http://en.wikipedia.org/wiki/Buffer_overflow

 

First of all, you posted your initial post yesterday at 4:54 PM (CET) which is after working hours so I had the very first opportunity to ask the developers about it just now.

Secondly, the article about buffer overflow at Wikipedia is irrelevant and is about completely different problems. In the screenshot you posted, only the buffer errors are visible so if they are actually followed by a "success" result it's no problem whatsoever. (By the way, every program generates this type of results, including explorer.exe.)

 

informed you 3 days ago via PM, no reply on that... you posted here yesterday past working hours as well as earlier this morning...

ahm, at loss - what is the difference, "success" aside, between buffer overflow caused by ekrn.exe and buffer overflow in the article?

so you are saying, coders do not need to care about about buffer overflows at all and that the behavior exkn.exe is exhibiting is perfectly normal? that would be an interesting QA policy.

 

Vtol,

Rather than having a personal vendetta against the ESET staff, which is patently clear throughout all your postings, why not get your facts right first?

Read this article:

http://blogs.technet.com/b/markrussinovich/archive/2005/06/04/buffer-overflows-in-regmon-traces.aspx

I quote:

Of course, I'm expecting you to say that Mark Russinovich doesn't know what he's talking about - even though he's probably the most skilled Windows guy around.



Jim

 

Procmon logs should be analyzed only by programmers as they understand the real meaning of the messages in the log. To common users, they may appear like errors but in fact they are just a normal result of calling a specific function. If they are followed by a "success" result, it's perfectly ok and expected. Every program generates this type of results, including system files.

I was talking about the buffer overflow messages in the Procmon log. Of course, buffer overflows are a security problem that shouldn't occur.

 

you can assure the NOD users that those buffer overflows by ekrn.exe are entirely benign and there is no way they can be exploited?

 

Sure. You can create a new PML log without any filters applied and you'll see "buffer overflow" probably next to each of the running processes. I've run PM for a few seconds and the following processes generated the "error":

Procmon2_9.exe
Explorer.EXE
csrss.exe
services.exe
lsass.exe
svchost.exe
spoolsv.exe
ekrn.exe
era.exe
SearchIndexer.exe
GoogleDesktop.exe
OUTLOOK.EXE
VpxClient.exe
wmiprvse.exe
verclsid.exe
iexplore.exe
firefox.exe
WINWORD.EXE
jqsnotify.exe
rundll32.exe
SearchProtocolHost.exe
SearchFilterHost.exe

 

why do you deviate from ekrn.exe? thought this is about NOD... I am in touch with others vendors as well to resolve their buffer overflows.

back on topic - your 'sure' is then an official statement by Eset that those buffer overflows caused by ekrn.exe are entirely benign and cannot be exploited in any way? would appreciate a clear statement and not some talking around the bush

 

Why not take the time to read the link I posted? It clearly says that a REG QUERY call to to a registry key, where that registry key contains > 132 bytes, will return this BUFFER_OVERFLOW message.

As Mark Russinovich sasys, it was a bad choice of message wording. Returning "MORE_DATA_AVAILABLE" would be better.

So this is NOT a buffer overflow error. And besides, it's Windows that returns this, it's got nothng to do with ESET.

There is no "clear statement" for ESET to make, as there is no buffer overflow. Windows is merely saying that there are more than 132 bytes stored in this registry key.

Comprende?



Jim

 

Well said, that's exactly what the message in Process Monitor is all about. Even system processes as well as other applications produce the message in ProcMon logs.

 

there nothing personal or vendetta - please point where you read as such. what is the problem of asking? and not getting replies? - read the question marks all over the initial post? comprende?

and there not just REG QUERY shown - please be thorough prior brushing off others

 

been there, not? forum is not about other processes but NOD. sad that you as NOD mod need to quote an incomprehensible statement, not very assuring. but it makes crystal clear that NOD is not going to do anything about...

 

You probably don't understand that every process / application produces the same messages, be it Norton, Kaspersky, ESET or Office, Google Desktop, system processes like svchost, explorer, etc. The official statement is that the messages you're seeing pose absolutely no security risk. Process Monitor logs are intended only for programmers and trained people, normal people would misinterpret the messages it produces.

 

that certainly true, yet it does not mean that 'normal people' are not to discover bugs and the like or to ask concerned questions as even being not so elite curiosity might still be applicable to 'normal people'.

I do understand well but cannot help to notice that quite a few of those are getting fixed frequently by various vendors for different products, when discovered as security risk. hence this been raised here in the official Eset forum about NOD.

much obliged!

 

Yes, but this is surely not a buffer overflow issue. It's merely determination of how large buffer is required for the result of a function, nothing less and nothing more.

 

and that applies to RegQueryValueKey as well as to IRP_MJ_QUERY_VOLUME_INFORMATION?

comparing the article Jim cited about RegQueryValueKey to this one about IRP_MJ_QUERY_VOLUME_INFORMATION there seems to be a bit of a difference, latter involving File System Filter Drivers?

anyway, you cited above the official Eset statement and thus things should be peachy and one not to worry