Dailydave mailing list archives
Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1)
From: L.M.H <lmh () info-pull com>
Date: Fri, 17 Nov 2006 19:21:48 +0100
On 11/17/06, Steve Grubb <sgrubb () redhat com> wrote:
What I was thinking of (but poorly articulated) was could anybody rootkit my machine with the ext3 softlockup detected bug? That I'd love to see.
You didn't mention the bug at issue, neither in the paragraph I quoted nor the ones above. A soft lock up is a DoS bug. No doubt. But that doesn't change the fact that others are certainly of higher risk, such as broken net. code which is happily exploitable.
Also, I was curious if anyone out there has been taking these images and putting them on a USB stick and trying them out? I'd be curious what the results are and how much you had to do to actually get a crash in a simulated "attack".
Steve, why you pretend to be 'cool' off list and then send this kind of misinformation out there (I'm referring to the whole message).
We don't ship JFS so I didn't care.
Thanks for clarifying it's Red Hat who's taking care of the bugs and not someone else. So everyone but Red Hat won't have fixes Red Hat does not know about. Nice. Emphasis on *we*.
I don't work in QA - never have.
The business card you gave me has QA Lead on it. It's sitting on my desk right now. Lies have a short life, so does a 12K image upload time.
Crashing the machine outright is interesting. Noisy output to syslog is not. For example, you have http://projects.info-pull.com/mokb/MOKB-12-11-2006.html this is typical of the stuff that is uninteresting. I downloaded this image and put it in cfs directory and ran it through the test:
That particular bug makes the kernel get into an infinite loop, at leas here, and I'm prolly using FC6 for testing and FC5 for development.
Because it was public knowledge and I was trying to motivate some people to get the patch out of bugzilla and into people's hands. That's all.
What? Public knowledge? You have serious inconsistencies in the arguments you've been using. No one except you knew about it by that time, I toke enough care to make sure you (at that time) knew it and you've been the only one knowing about it. You should read Tom Clancy's work, they've got a couple dirty tricks there you'll find useful for daily life. Seriously. Sometimes it's good to know how much you want to go down before you're unable to push yourself up again (just a suggestion).
ROTFL...Hey, I've been married twice and the crocodiles might be more favorable. :D
Hah, well, worst of all is when kids grow up enough to start a My Space addiction (specially females) ;-)
The dates in bugzilla speak for themselves.
Thankfully they do, so does the timing and the information about our meeting at Baltimore.
One thing I'd like to point out from this week's batch of bugs is this one: http://projects.info-pull.com/mokb/MOKB-14-11-2006.html This has nothing to do with SE Linux. Its purely an hfs issue and the patch is a 1 liner. The SE Linux code was passed a NULL pointer from the hfs subsystem.
So SELinux isn't checking if data coming from the outside (that is, via LSM hooks like in this case) is actually valid. How comes that's not a flawed assumption from the SELinux side? Eric also agreed in the Kernel Fun blog about 'hardening SELinux hooks' to ensure they can act properly on invalid input. Your failure here is that you're unable to see this from the perspective of someone who breaks stuff. You are lacking context here. Lemme explain: - hfs fails to deal with a corrupted fs stream - tries to mount it and then initialize journaling - LSM hook catches it, sends the structures to the first security module, SELinux in this case. - SELinux says: Oh, fine, thanks for the data. - SELinux tries to get information from an invalid memory address. HFS is a vector to attack SELinux. LSM is the execution path allowing us to use that vector. SELinux is the vulnerable point. Now, let's bring a way more graphical representation of this problem. I came through a rather a funny forum on Jackass stuff. That is, sick, crazy people thinking about ways to get in some serious shit (even literally). Someone else proposed a totally screwed up thing (whoever that guy was, he needs urgent care and inspection at the Pescadero State Hospital). Basically a wall full of holes and a bare naked guy standing towards it, with a donkey in mating time or fed up with pheromones. You can imagine the rest. SELinux would be the bare naked guy. The wall full of holes would be the LSM framework, and the donkey would be the Bad Guy (tm).
Another thing I'd like to point out regarding Linux is that you can turn off the automounter. In FC6 you just click on "Application" | "System Tools" | Configuration Editor". That brings up gconf-editor and you select "Desktop" | "Gnome" | "Volume Manager" in the left hand browser window. In the right hand is 2 entries: automount_drives and automount_media. Uncheck them.
MoKB is done from the 'bugged by default' perspective. I take an unmodified platform, pristine and only modified with upstream patches, without touching anything that could alter the conditions. Cheers. _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) PERFECT . MATERIAL (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Gadi Evron (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 13)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 17)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) L . M . H (Nov 17)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Gadi Evron (Nov 12)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) PERFECT . MATERIAL (Nov 11)
- Re: Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1) Steve Grubb (Nov 12)