Linux kernel securityhttp://lwn.net/Articles/118251/
Mislim da autora/autore nije potrebno posebno predstavljati...
Citat:
2) Linux Kernel advisory introduction
Let me begin by giving you a timeline:
December 15th: I send Linus a mail with a subject line of
"RLIMIT_MEMLOCK bypass with locked stack"
December 27th: The PaX team sends Linus a mail with a subject line of
"2.6.9+ mlockall/expand_down DoS by unprivileged users"
January 2nd: The PaX team resends the previous mail to Linux and Andrew
Morton
Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.
Let me begin by giving you a timeline:
December 15th: I send Linus a mail with a subject line of
"RLIMIT_MEMLOCK bypass with locked stack"
December 27th: The PaX team sends Linus a mail with a subject line of
"2.6.9+ mlockall/expand_down DoS by unprivileged users"
January 2nd: The PaX team resends the previous mail to Linux and Andrew
Morton
Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.
Prije svega uočite pomalo frustrirani ton kojim je poruka napisana..
Citat:
Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* |grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter
of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4.
It's a pretty sad state of affairs for Linux security when someone can
find 4 exploitable vulnerabilities in a matter of minutes. Since there
was no point in sending more vulnerability reports when the first hadn't
even been responded to, I'm including all four of them in this mail, as
well as a POC for the poolsize bug. The other bugs can have POCs
written
for just as trivially. The poolsize bug requires uid 0, but not any
root capabilities. The scsi and serial bugs depend on the permissions
of their respective devices, and thus can possibly be exploited as
non-root. The scsi bug in particular has a couple different attack
vectors that I haven't even bothered to investigate. Some of these bugs
have gone unfixed for several years.
of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4.
It's a pretty sad state of affairs for Linux security when someone can
find 4 exploitable vulnerabilities in a matter of minutes. Since there
was no point in sending more vulnerability reports when the first hadn't
even been responded to, I'm including all four of them in this mail, as
well as a POC for the poolsize bug. The other bugs can have POCs
written
for just as trivially. The poolsize bug requires uid 0, but not any
root capabilities. The scsi and serial bugs depend on the permissions
of their respective devices, and thus can possibly be exploited as
non-root. The scsi bug in particular has a couple different attack
vectors that I haven't even bothered to investigate. Some of these bugs
have gone unfixed for several years.
I na kraju razmišljanje pax tima...
Citat:
I'd really like to know what's being done about this pitiful trend of
Linux security, where it's 10x as easy to find a vulnerability in the
kernel than it is in any app on the system, where isec releases at
least one critical vulnerability for each kernel version. I don't see
that the 2.6 development model is doing anything to help this (as the
spectrum of these vulnerabilities demonstrate), by throwing
experimental code into the kernel and claiming it to be "stable".
Hopefully now these vulnerabilities will be fixed in a timely manner.
Linux security, where it's 10x as easy to find a vulnerability in the
kernel than it is in any app on the system, where isec releases at
least one critical vulnerability for each kernel version. I don't see
that the 2.6 development model is doing anything to help this (as the
spectrum of these vulnerabilities demonstrate), by throwing
experimental code into the kernel and claiming it to be "stable".
Hopefully now these vulnerabilities will be fixed in a timely manner.
Nedavno je tema koju sam pokrenuo bila zaključana nakon "zagađenja" :) a u kojoj ekscentrični Theo de Raadt daje vrlo ružne komentare na račun kvalitete linux kernel koda. Theo je možda socijalno retardiran fanatik, ali je prije svega vrhunski programer i sw inženjer, zaista je tužno što se većina komentara svela na "Theo sux", "OpenBSD sux" i sl.
Ukratko, mislim da se cijeli njegov stav može vidjeti u ovoj izjavi:
http://article.gmane.org/gmane.os.openbsd.misc/83740
Citat:
If the Linux people actually cared about Quality, as we do, they would
not have had as many localhost kernel security holes in the last year.
How many is it... 20 so far?
not have had as many localhost kernel security holes in the last year.
How many is it... 20 so far?
Ustvari brojka je prilično veća od 20 :) Bar toliko postoji javnih exploita, privatnih puno više, a bugova...uff, tko bi ih stigao izbrojati...
Theo također spominje da je "OpenBSD about quality" i mislim da u tome ima pravo. Naglašava svoj tim od 60 ljudi koje drži tighly focused može uraditi stvar puno kvalitetnije nego 6000 programera koji su desinkronzirani i decentralizirani, te bez nadzora. OpenBSD je poznat po svojoj "proaktivnoj sigurnosti" i kriptografiji nativno podržanom u OS-u, te po timovima od 10-ak ljudi koji redovito vrše audite koda u potrazi za sigurnosnim propustima.
Zanimaju me Vaša razmišljanja o temi kvalitete razvoja kernela i modelu koji je danas prisutan (ljudi šalju patcheve i ovise o hirovima maintainera), te usporedbe sa drugim OS-evima.
Sam OpenBSD moža nije toliko fancy što se tiče installera (hi axez :) i podrške za uobičajeni PC hardver (modemi, grafičke karte...), ali to mu nije ni namjena. Glavni design goal mu je tvrda UNIX filozofija i kvaliteta.
Linus je u više navrata rekao da je spreman raditi kompromise koji se tiči i sigurnosti i dizajna, ukoliko ti kompromisi uvjetuju veći prodor na tržište. Ja mislim da su ti kompromisi već danas doveli do nesrazmjera, kad je potrebna "čvrsta ruka" kako se ne bi bilo kakva đubrad primala u glavno razvojno stablo, a ovakvi sigurnosni savjeti od pax tima odgađali po 3 tjedna.
Razmišljanja?
Molim trollove da se drže izvan ove teme.
[EDIT:] Mislim da je jedan od ključnih komentara u raspravi koja slijedi, ovaj:
Citat:
(Posted Jan 9, 2005 17:13 UTC (Sun) by guest PaXTeam) (Post reply)
everything i discussed here very much belongs to the public and it shall stay so. i see you are quick to accuse others of being irresponsible but don't actually have the guts to apologize when your claims prove to be without merit. you also haven't realized that there are bigger issues here than the fate of a handful bugs, which is the whole point why we tested the waters with them only, not more critical stuff. some questions for you and the community to answer: why can the BSDs have a designated security officer and linux not? why can you communicate with said officers using proper encryption whereas you cannot with vendor-sec? why did nothing happen after the do_brk() bug/exploit leak more than a year ago so just in time history could repeat itself with the uselib() bug/exploit? why didn't you, Steve Bergman, complain about *that* yet? why is it acceptable that isec can release local root exploits with their advisories (which are anything but simple to understand and hence reproduce) but a few liner in assembly (trivial to reproduce) makes you scream 'irresponsible'? hipocrisy abound and you talk about holding others to higher standards
everything i discussed here very much belongs to the public and it shall stay so. i see you are quick to accuse others of being irresponsible but don't actually have the guts to apologize when your claims prove to be without merit. you also haven't realized that there are bigger issues here than the fate of a handful bugs, which is the whole point why we tested the waters with them only, not more critical stuff. some questions for you and the community to answer: why can the BSDs have a designated security officer and linux not? why can you communicate with said officers using proper encryption whereas you cannot with vendor-sec? why did nothing happen after the do_brk() bug/exploit leak more than a year ago so just in time history could repeat itself with the uselib() bug/exploit? why didn't you, Steve Bergman, complain about *that* yet? why is it acceptable that isec can release local root exploits with their advisories (which are anything but simple to understand and hence reproduce) but a few liner in assembly (trivial to reproduce) makes you scream 'irresponsible'? hipocrisy abound and you talk about holding others to higher standards
.
Re: Linux kernel security
Re: Linux kernel security