APRIL 08, 2004 (COMPUTERWORLD) - There are many myths surrounding computer network security that are counterproductive to finding a true solution to the problem. One of these is the belief that vendors should speed up the process of producing and releasing patches for security vulnerabilities that have been discovered by security researchers. Instead, we need a completely different solution to the patch management problem, and part of the solution involves slowing down, not speeding up, patch releases.
Slow them down? What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.
First, let's define zero-day exploit. An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature. The zero-day type of exploit is discovered, not as part of the security research process, but when an active exploit is using a vulnerability the software developer was previously unaware of. Many different groups at that point rush to reverse-engineer the exploit to document the vulnerability. Antivirus vendors compete to be first to announce a method to detect and fix the exploit, and the software vendor must devise and release a patch immediately to combat the exploit.
By far, the most common type of exploit is the buffer overflow, and software vendors are spending millions of dollars to find and prevent these types of vulnerabilities. These vulnerabilities still exist -- they are getting fewer in number, however, and finding them is now much more difficult. Part of my consulting practice to software vendors and their major customers is finding and reporting these types of vulnerabilities. Where I used to be able to do the "find vulnerabilities blindfolded with one arm tied behind my back" routine, I now actually have to work to find them in major software products.
Researchers are motivated to find these remaining vulnerabilities either by a desire to make a name in the software security industry ("Discoverer of the wack-a-mole vulnerability in Linsoft 2004") or, as in my case, because they are getting paid by the vendor or major customers for this research. Independent researchers will report their findings to CERT, and the vendor and researchers will report the vulnerability to the vendor and the client. Working from a black-box approach, this work is painstakingly detailed and involves searching and reading through millions of lines of disassembled software code. Even when you find a buffer overflow the vendor has missed, it may not lead directly to an exploitable vulnerability.
The easy way to find a vulnerability
Code exploiters (some would call them hackers) know that this is long, detailed, potentially thankless work. Their goal is not to discover if or where a flaw exists. Their goal is to create software that takes advantage of a flaw that already exists. They know there is a much easier way to determine the details of a particular vulnerability than slogging through millions of lines of assembly. The code exploiters use the same tactics against the software vendors that the software vendors and antivirus companies use on them. They wait until the patch for the vulnerability is released, then they reverse-engineer the patch. This is orders of magnitude easier than finding the vulnerability directly.
For example, the patch for the SQL Slammer worm was released six months before the exploit was launched. This long delay enabled blame to be placed on lax systems administrators for not properly patching systems. T
Slashdot Mirror
Verbing nouns weirds language.
First edit the file in binary mode
:%!xxd
vim -b datafile
Now convert the file to a hex dump with xxd
Well, I thought it was cool.
I dunno, coastguard?
My philosphy is: If have spare parts left over when you put it back together, you're better than the engineers that designed it...
It'll be Google, they won't cease until they've indexed the world.
If you are certain you won't get the job, then no, don't bother. Nothing ventured, nothing gained, etc.
Why do you get almost everything else almost always more than 4 months ahead of Europe?
A paper edition would certainly be a welcome money-spinner for the project...
+1 Funny
5. ??? 6. Profit!
Slow down the security patch cycle
Opinion by Bill Addington
APRIL 08, 2004 (COMPUTERWORLD) - There are many myths surrounding computer network security that are counterproductive to finding a true solution to the problem. One of these is the belief that vendors should speed up the process of producing and releasing patches for security vulnerabilities that have been discovered by security researchers. Instead, we need a completely different solution to the patch management problem, and part of the solution involves slowing down, not speeding up, patch releases.
Slow them down? What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.
First, let's define zero-day exploit. An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature. The zero-day type of exploit is discovered, not as part of the security research process, but when an active exploit is using a vulnerability the software developer was previously unaware of. Many different groups at that point rush to reverse-engineer the exploit to document the vulnerability. Antivirus vendors compete to be first to announce a method to detect and fix the exploit, and the software vendor must devise and release a patch immediately to combat the exploit.
By far, the most common type of exploit is the buffer overflow, and software vendors are spending millions of dollars to find and prevent these types of vulnerabilities. These vulnerabilities still exist -- they are getting fewer in number, however, and finding them is now much more difficult. Part of my consulting practice to software vendors and their major customers is finding and reporting these types of vulnerabilities. Where I used to be able to do the "find vulnerabilities blindfolded with one arm tied behind my back" routine, I now actually have to work to find them in major software products.
Researchers are motivated to find these remaining vulnerabilities either by a desire to make a name in the software security industry ("Discoverer of the wack-a-mole vulnerability in Linsoft 2004") or, as in my case, because they are getting paid by the vendor or major customers for this research. Independent researchers will report their findings to CERT, and the vendor and researchers will report the vulnerability to the vendor and the client. Working from a black-box approach, this work is painstakingly detailed and involves searching and reading through millions of lines of disassembled software code. Even when you find a buffer overflow the vendor has missed, it may not lead directly to an exploitable vulnerability.
The easy way to find a vulnerability
Code exploiters (some would call them hackers) know that this is long, detailed, potentially thankless work. Their goal is not to discover if or where a flaw exists. Their goal is to create software that takes advantage of a flaw that already exists. They know there is a much easier way to determine the details of a particular vulnerability than slogging through millions of lines of assembly. The code exploiters use the same tactics against the software vendors that the software vendors and antivirus companies use on them. They wait until the patch for the vulnerability is released, then they reverse-engineer the patch. This is orders of magnitude easier than finding the vulnerability directly.
For example, the patch for the SQL Slammer worm was released six months before the exploit was launched. This long delay enabled blame to be placed on lax systems administrators for not properly patching systems. T