Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy |
|---|---|
| Date: | Thu, 27 Jan 2005 13:21:45 -0500 |
I think the joke is on you in this case. There is a large patch series of which you judge the first steps only. Those steps introduce the infrastructure and concepts into the kernel, and later patches will tweak the exact numbers to values with more entropy. ONCE THEY EXISTING INFRASTRUCTURE IS ACCEPTED AND DEBUGGED. Maybe you don't understand that, I assume a lot of the other readers of this list do. You don't plop a huge patch in the linux kernel in one chunk. You do it in nice small, incremental and debuggable steps.
If Exec-shield is any model for what you plan to turn this into, my comments still apply. If you like, I'll simply send out the same email months from now when you "finalize" this patch into the level of security you claim it to be able to provide (which will never happen, since you won't be providing any bruteforce deterrence, so it doesn't matter if you increase the randomization by a couple more bits). I should also add that the stack randomization present in this patch and that in exec-shield can be bypassed by tossing enough data into the stack, like "/bin/sh" over and over, since the amount of randomization is smaller than the stack itself. I should also note that the latest output of paxtest I could find against exec-shield shows that the amount of randomization for shared libraries is the same as in the patch you sent to LKML. So if your argument is that you agree these values are stupidly low, you're not saying much about your own "enterprise-grade" software ;) I would also like to correct a mistake in my previous mail. The glibc issues are indeed fixed in the latest FC3 glibc, which was released on December 27th, 2004, nearly 3 1/2 months after the bug was initially reported. The glibc update was not released as a security update however, so many users are still affected (like the two Fedora developers I contacted). -Brad
signature.asc
Description: Digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: [Full-Disclosure] spoolcll.exe - new worm being distributed viamysql vulnerability?, Dolan, Patrick |
|---|---|
| Next by Date: | Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy, Michal Zalewski |
| Previous by Thread: | Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy, Arjan van de Ven |
| Next by Thread: | Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy, Michal Zalewski |
| Indexes: | [Date] [Thread] [Top] [All Lists] |