On Sun, Feb 20, 2005 at 10:38:07PM +0200, Alex Behar wrote: > On Saturday 19 February 2005 08:29, Tzafrir Cohen wrote: > | > | On Sat, Feb 19, 2005 at 02:20:19AM +0200, Alex Behar wrote:
> | The article was not about this. It was about responsiveness. My > | knowledge of Windows is not good enough for that. > | > | It normally takes a while for exploits to be generated and propagate, > | just like updates. The holes shouldn't have been there in the first > | place, but they are. > Thats a common mistake most people do. Most vulnerabilities become published > to circles of people related to the researchers long before they are even > reported to the vendor, especially if it's Microsoft. I'm aware of that. And this is why I questioned the author's MS data. BTW: anyone with a link for more information? I still base what I write on a third-hand report from that article. > > | > | Workarounds such as non-executable stack which you seem to admire only > | make it more difficult to write expliots. But then again, as such > | techniques become more common then so will working aaround them become > | faster. > Such are out for a while, they make the trivial exploitation of a hole a lot > harder than a hardcoded (semi)universal targets, like the exploits published > for Windows. A quote comes to my mind as to "making the theretical practical". If there is a way to manually exploit this, it will be automated. > > | > | The question that study tries to check is "how big is the window of > | exposure?". > The window of exposure from the public advisory to the patch varies. Most > researchers do not release such unless the vulnerability is fixed and patches > are out. We speak about close to zero-day attacks here, thats where security > > hardening really matters. > > > | > | I have no idea where it has the data of windows holes from. e.g: how > | does he know exactly since when these holes were known. Only recently we > | were told about major security holes that were reported to MS and not > | published for monthes. > | > | RedHat simply cannot afford to delay fixes for too long, because others > | will patch the same problem soon and this will look quite bad for RH. > | However does it have resources to issue relible fixes fast enough? > Again - Gentoo for example release fixes really fast, sometimes (as seen in > the recent Glftpd advisory) in less then two hours. > That all boils down to the competence of the RedHat Security Response Team. And how well are those patches tested? I've seen too many security fixes that break the system. The security patches issued by distros have to be checked so that they avoid breaking existing systems. And this is often not as easy as it sounds. If security patches of a certain vendor has a resonable chance of breaking your system you'll do more testing (locally) before applying them. The result: fixes will be distributed slower. Microsoft has earned such a reputation, and thus too many users avoid automatic installations of its fixes. > > | > | There is also the bias regarding the quantity: RHEL (or any linux distro) > | is basically the equivalent of not only the base windows 2003 but of > | windows2003 with quite a few extra softwares. Such a research should > | also include MS-Office, exchange, etc. > > > | > | And then, as someone already mentioned, there is the issue of sevirity. > | If there is a buffer-overflow in apahe, sshd or whatever you need a fast > | fix for it. Some other issues can wait a bit longer (to get better QA). > | There is no guarantee that MS actually issues fixes to such holes. Or > | that it doesn't bundel several of those together to reduce the number of > | "known problems problems" with the OS. > > How does functionality relates to the topic here? Try to write a worm that explits a symlink attack to penetrate computers. > > There are loads of design errors Microsoft have not addressed in the current > Windows releases that can make the job of the attacker easier and tripple her > chances. Because > > On Gentoo-hardened, Adamantix - even OpenBSD boxes, there are no default > targets or any chance to brute force such, as utilities like the PaxTest > suite prove. There are a number of "hardening" product for windows as well. Not that I have any idea about their effectiveness, but I would like someone with more relevant expirince to be the judge of that. > If you use PaX and your tool chain and libc are compiled > properly, crashing the (Apache or whatever) thread, which happens a lot > during the bruteforce process, will mean a change of the memory layout of the > thread because of ASLR, thus killing any bruteforcing attempts. There are a > lot of noisy log messages and in cases where RSBAC or SELinux are in place, > after a certain crashing threshold the process is terminated and not started > again, rendering the service useless to the attacker and leaving enough > forensics evidence. I leave the calculations of the probability of properly > hitting a function pointer address or any other usable data to you. Even if > you manage to leak any usable information about the memory space of the > remote application through, lets say, a format string vulnerability, you > chance of executing code are small due to ProPolice or PAGEEXEC. I'm impressed. But I bet there are still clever ways to exploit holes and they will be automated. Linus has avoided adding such fixes to Linux (the kernel) for exactly that reason: to avoid over-confidence of inexplotability of holes. > > Having said that, there are still ways, although very complex, to exploit > remotely such vulnerabilities. However, these techniques do not guarantee a > 100% protection for the unpatched application, but they come really close. You don't need 100% to spread a worm. I bet 10% will also be quite useful. -- Tzafrir Cohen | New signature for new address and | VIM is http://tzafrir.org.il | new homepage | a Mutt's [EMAIL PROTECTED] | | best ICQ# 16849755 | Space reserved for other protocols | friend ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
