On Saturday 19 February 2005 08:29, Tzafrir Cohen wrote: | Hi | | Please stick to the point | | On Sat, Feb 19, 2005 at 02:20:19AM +0200, Alex Behar wrote: | > The comments are inline. | > | > On Friday 18 February 2005 23:19, Tzafrir Cohen wrote: | > | Hi | > | | > | Could anybody give a direct reference to the lecture notes or something | > | similar? I have only read the report in the link above | > | | > | On Fri, Feb 18, 2005 at 05:58:34PM +0200, Alex Behar wrote: | > | > Well, it all depends on how he defines security in Linux. RedHat | > | > 6.2-secure or Adamantix/Hardened Gentoo-secure? | > | > These last two beat Windows-based solutions out of the box any time, | > | > and they have a pretty good chance surviving zero-day threats. | > | | > | This research did not check the level of security. It checked one of | > | its parts: response to advisories. | > | | > | And it specifically checked a certain high-profile linux distribution. | > | | > | > All that, when Microsoft "advertise" that they are more secure | > | > compared to RedHat, because they have less unpatched holes for the | > | > same period of time, before releasing a patch. That is a complete | > | > joke! We all know Redhat (not Fedora) is junk. | > | | > | I don't consider RedHat's level of security to be "joke". It certainly | > | has sane defaults generally. | > | | > | > It worked its way down during the years to become the most | > | > windows-like distribution out there and it is probably worsened since | > | > the last time I checked. Although Fedora do surprise me, in a good | > | > way of course, they still have a lot of work to do until they get to | > | > the level of Gentoo-hardened or Adamantix - both from a security | > | > point of view, and from ease of maintenance. | > | | > | Please check again. The defaults have become much better than in the | > | days of RH62. It will now turn off most unnecessary services, install a | > | simple iptables firewall by default etc. | > | > Firewalling and "sane defaults" cannot protect you against zero day | > attacks, just like windows update can't - especially with the current | > publically available techniques. That's where security really matters, | > defending agains real world threats, not some automated publically-known | > attack by a tool like Core Impact, CANVAS or just a script kiddie with an | > exploit at his disposal. | > | > | But this is not the issue here. | > | > Ofcourse it is. There is no secure code and we all know that. There are | > simply too many things that can go wrong, thats why we need to approach | > the same problem from a few different angles in order to better protect | > ourselves. Coder make mistakes, they we are only human. Some make more | > then others... | | 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.
| | 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. | | 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. | | 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? 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. 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. 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. 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. I do believe that guy is a clown, mostly because I am well aware of most public and some private exploitation methods, and I see how the compare in both OS. Kind regards, Alex -- The difference between theory and practice, is that in theory, there is no difference between theory and practice.
pgpOAcHIjtBYq.pgp
Description: PGP signature
