ekrn.exe buffer overflow

Discussion in 'ESET NOD32 Antivirus' started by vtol, Nov 4, 2010.

Thread Status:
Not open for further replies.
  1. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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:cool:
    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)

    04-11-2010 16-39-35.png
     
    Last edited: Nov 4, 2010
  2. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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
     
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.)
     
    Last edited: Nov 5, 2010
  4. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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.
     
  5. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    668
    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
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  7. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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?
     
  8. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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
     
    Last edited: Nov 5, 2010
  9. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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
     
  10. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    668
    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
     
  11. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  12. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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
     
  13. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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...
     
  14. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  15. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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!
     
  16. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  17. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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
     
Thread Status:
Not open for further replies.