Contributed by deanna on from the little-things-mean-a-lot dept.
05: SECURITY FIX: November 19, 2006 All architectures
The ELF ld.so(1) fails to properly sanitize the environment. There is a potential localhost security problem in cases we have not found yet. This patch applies to all ELF-based systems (m68k, m88k, and vax are a.out-based systems).
The patch is also available for 3.9.
(Comments are closed)
By Anonymous Coward (85.178.102.76) on
they`re using fuzzing to find holes in Kernel-Code (related to FS-Code mostly).
Does OpenBSD do the same to ensure the quality of the Code?
I ask because OpenBSD has ext2 support wich is maybe inspired by Linux-Code and Linux seams to have issues with nearly all FS...
Also a UFS-bug in fBSD was found.
So it`s propably interesting to know if the developers do use fuzzers to ensure that the Kernel wont panic even the FS is crappy.
Comments
By Krunch (139.165.82.240) on http://krunch.be/
> they`re using fuzzing to find holes in Kernel-Code (related to FS-Code mostly).
I didn't knew about the MoKB project but I remember about this.
Comments
By Anonymous Coward (219.90.242.185) on
I daresay it could break some other interesting stuff.
Comments
By djm@ (203.217.30.85) on
>
> I daresay it could break some other interesting stuff.
I got curious and ran the fuzzer for a couple of hours to test the ELF loader and didn't find anything (i386). Running the fuzzer on filesystems (I think there is a BSD port now) and reporting crashes would be a great project for someone, even someone without coding experience.
-d
Comments
By grg (219.90.242.86) on
I've tested ffs and cd9660 - no issues found yet. I'll test some of the other supported filesystems in due time.
By dingo (198.208.251.24) on
> they`re using fuzzing to find holes in Kernel-Code (related to FS-Code mostly).
I've seen this as well. They only recently ported this to BSD, and did a fuzz on freebsd. I'd like to see them bounce it off openbsd. This would give a good indicator of both the quality of the fuzzer, and the quality of code in openbsd.
A good lint(1) can find bugs in linux and freebsd code... just my opinion as only a moderate level c programmer.
Comments
By Anonymous Coward (149.9.0.27) on
> > they`re using fuzzing to find holes in Kernel-Code (related to FS-Code mostly).
>
> I've seen this as well. They only recently ported this to BSD, and did a fuzz on freebsd. I'd like to see them bounce it off openbsd. This would give a good indicator of both the quality of the fuzzer, and the quality of code in openbsd.
>
> A good lint(1) can find bugs in linux and freebsd code... just my opinion as only a moderate level c programmer.
Well OpenBSD claims to do Pro-Active Security and using fuzzers would be a step ahead on that road.
I realy wondered that NO developer simply posted here and said: Well we`ve tested our FS-Code also with Fuzzers
No matter if you do code good or not some day you`ll do a misstake and Fuzzers could help to find those in such Implementations.
And I angree that lint is mostly helpfull for novice programmers (at least the openbsd lint) but thatīs why it should get improved, or? :-)
Comments
By Miod Vallat (82.195.186.220) miod@ on
Oh but we did at some point (especially using Apple's fsx). Not all problems exposed have been fixed, though.
Comments
By Anonymous Coward (137.226.13.2) on
>
> Oh but we did at some point (especially using Apple's fsx). Not all problems exposed have been fixed, though.
Thanks for your post miod! :)
I hope I donīt understand you wrong so the answer would be "No we did not tested everything with Fuzzers".
Well the MoKB is realy scarry because mount seams to simply mount the FS (so it`s valid for mount) even it`s brocken.
Such modifications can be done or can propably even happen (power went of, FS gets "corrupted").
I also could imagine, even I realy did not tested anything (no time) that there also other problems (not related to the FS) like handling corrup ELFs (at least on Linux propably). Well it would be horror if any user could crash the OS (propably also OpenBSD) by just running a "corrupt" elf. I mean there also file-fuzzers and the risk seams to be real at least
for Servers with more then one user (shell-servers or other kind of servers).
Just the imagination itself and that oBSD "could" propably have one or two issues scars me already. It`s more Horror then any Steven King-Movie. ;]
Is there any "manual" or guide wich propably tells interested users how OpenBSD developers do check their code? Propably also with used tools (others then lint) wich help to point out issues or tools wich do help to try to provoke issues (fuzzers f.e.).
OpenBSDs Code is great and the most secure I do know so propably other developers would be interested into the methods used to ensure the code-quality. :)
Comments
By pyr (193.252.148.11) pyr@spootnik.org on http://spootnik.org
> >
> > Oh but we did at some point (especially using Apple's fsx). Not all problems exposed have been fixed, though.
>
> Thanks for your post miod! :)
> I hope I donīt understand you wrong so the answer would be "No we did not tested everything with Fuzzers".
>
> Well the MoKB is realy scarry because mount seams to simply mount the FS (so it`s valid for mount) even it`s brocken.
> Such modifications can be done or can propably even happen (power went of, FS gets "corrupted").
>
> I also could imagine, even I realy did not tested anything (no time) that there also other problems (not related to the FS) like handling corrup ELFs (at least on Linux propably). Well it would be horror if any user could crash the OS (propably also OpenBSD) by just running a "corrupt" elf. I mean there also file-fuzzers and the risk seams to be real at least
> for Servers with more then one user (shell-servers or other kind of servers).
>
> Just the imagination itself and that oBSD "could" propably have one or two issues scars me already. It`s more Horror then any Steven King-Movie. ;]
>
> Is there any "manual" or guide wich propably tells interested users how OpenBSD developers do check their code? Propably also with used tools (others then lint) wich help to point out issues or tools wich do help to try to provoke issues (fuzzers f.e.).
> OpenBSDs Code is great and the most secure I do know so propably other developers would be interested into the methods used to ensure the code-quality. :)
This is
Comments
By pyr (193.252.148.11) pyr@spootnik.org on http://spootnik.org
> > >
> > > Oh but we did at some point (especially using Apple's fsx). Not all problems exposed have been fixed, though.
> >
> > Thanks for your post miod! :)
> > I hope I donīt understand you wrong so the answer would be "No we did not tested everything with Fuzzers".
> >
> > Well the MoKB is realy scarry because mount seams to simply mount the FS (so it`s valid for mount) even it`s brocken.
> > Such modifications can be done or can propably even happen (power went of, FS gets "corrupted").
> >
> > I also could imagine, even I realy did not tested anything (no time) that there also other problems (not related to the FS) like handling corrup ELFs (at least on Linux propably). Well it would be horror if any user could crash the OS (propably also OpenBSD) by just running a "corrupt" elf. I mean there also file-fuzzers and the risk seams to be real at least
> > for Servers with more then one user (shell-servers or other kind of servers).
> >
> > Just the imagination itself and that oBSD "could" propably have one or two issues scars me already. It`s more Horror then any Steven King-Movie. ;]
> >
> > Is there any "manual" or guide wich propably tells interested users how OpenBSD developers do check their code? Propably also with used tools (others then lint) wich help to point out issues or tools wich do help to try to provoke issues (fuzzers f.e.).
> > OpenBSDs Code is great and the most secure I do know so propably other developers would be interested into the methods used to ensure the code-quality. :)
>
> This is
>
Oops
This: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
Shows that at least the linux elf-loader tries to to what it can to load an executable, at the expense of checking if it is valid.