Comodo punts buffer overflow protection

Inaccuracy

"The idea is to leave hostile code in memory following the crash, at a location where it is subsequently executed once a system is restarted."

Thats not a buffer overflow, and heres why;

Memory isn't retained in any useful way after a "system is restarted", memory is volatile and doesn't remain in use after a reboot, and of course all allocations are new and software should never point to the same exact location in the chips after being allocated a second time, that and the natural state of decay of memory during a reboot would make this idea so very flawed it shouldn't have been published.

So what is a buffer overflow? Well as you don't seem to have a grasp on this let me explain...

The trick is to overflow a buffer (obviously), typically a string without correct bounds checking, so for instance if I took;

char bleh[5]; //allocate a string of 5 bytes max length

then did;

strcpy(bleh, "THIS IS A LOT LONGER THAN THE 5 BYTES I ALLOCATED");

I would be over-writing some part of memory as strcpy doesn't check the size of the buffer its copying into. Typically the stack is modified, munging the heap is a lot harder as they heap is far bigger.

Now if I for instance copied into that string enough data to reach the eip register (extended instruction pointer) I would be able to specify an address for the function call that hasn't checked the buffer sizes to return to, which would have to be somewhere inside of my buffer because thats the part of memory I can control. So my eip overwrite needs to have a known location to return to, this is hard to get right, so i'd fill some NOP (no operation) instructions in, this is called a NOP sled, and as long as you point the execution back to somewhere in that NOP sled you should be able to execute a shell code, or egg after all of those NOP instructions have been processed, that egg can create a nice little shell prompt, or open a bind port, or any number of things which will allow more access to the system.

Maybe you need some more education on how these things work, there's a detailed article, credited as probably the most important free publication on buffer overflows ever to have been written.

You'll find this article at this address, http://www.phrack.org/archives/49/P49-14

Comodo BO tester

Sounds like software that sniffs your pits....

maybe should have been called Comodo BS tester, since it sound like that's what it is...

maybe they should rename the company to Commode.

Why are you printing this?

Granted, you did slam it at the end, but still why even bring this sort of crap into the light?

"Buffer overflow attacks take advantage of security bugs that mean computer systems can be crashed by a malformed input to vulnerable programs. The idea is to leave hostile code in memory following the crash, at a location where it is subsequently executed once a system is restarted."

Oh really, I will have to remember that the next time i write an exploit, seems hard to achieve though! And their 3 types of overflows seems more like 2 overflows and 1 exploitation technique to me. What this retarded little program probably does is try to execute code on the stack and on the heap, it then checks for statically maps libraries, which it will find unless you run vista.

Don't give these people a platform!

But does it *do* anything

I've got a quick test, requires no download and hardly any thought.

Answer the question "are you running a Windows PC connected to the Internet?"

If the answer is "yes" then you are potentially vulnerable to various attacks and need anti-virus, anti-spam, anti-phishing and firewall software.

So, how is my test different to their test except that they want you to use THEIR software and I just want you to use whatever software you want?

At 2 seconds

I bet it just searches for known programs: Ooh you have ZoneAlarm that means you're vulnerable.

Weird do - weird

"Buffer overflow attacks take advantage of security bugs that mean computer systems can be crashed by a malformed input to vulnerable programs. The idea is to leave hostile code in memory following the crash, at a location where it is subsequently executed once a system is restarted."

John L., this sounds like a fairy tale.

The best of all is the residue of malicious code in RAM for after the reboot. Buffer overflows do not necessarily lead to a crash, or are intended for one.

Let's leave it as a Friday Night in ElReg slip.

Memory page privileges

Yup, all the program is doing is testing for execution privileges in memory pages containing data. It doesn't mean that your security software is vulnerable to buffer overlows, just that *if* it were to be vulnerable the code would execute instead of page faulting.

It's something that should be dealt with by the OS.

two second check

I would guess that the only way to do this in two seconds is have a list of known processes and versions which are vulnerable to attacks, and walk the process list printing out 'hah you are vulnerable' if the said process is running.

Slow Friday...

..or about to miss a deadline?

Leyden, at least do a little more research and put more thought into what you write if you want to be taken seriously by more than the tin-foil crowd.

Please read wiki before post/write

Ok mates, first of all all tests are as fast as call any API (GetModuleHandleA in that tests. Dear user with a debugger, please try to read the code) from stack/heap or in ret2libc manner. You don't need to check any software for vulnerabilities to check if you PC is vulnerable to BO in general. If you enable DEP in AlwaysOn mode then you will see that DEP block 2 first tests as they're tryin' to execute stack and heap, and then DEP will fail the third test, as soon as it's vulnerable to ret2libc kind of attack.

There're a lot of various wiki/articles in the internet explainin' buffer overflow attacks, so please read before write some strange article like this one.