FreeBSD Kernel Leak 81
Pine Digital Security announced a FreeBSD kernel leak, found when auditing a customer. The leak can be exploited to panic the server or elevate privileges. FreeBSD swiftly updated CVS, a security advisory will probably follow. Both the -RELEASE branch and -CURRENT branch are vulnerable.
Re:First post (Score:2)
Does not effect OpenBSD or NetBSD (Score:2, Informative)
submitted the article didn't feel it was
necessary.
To repeat myself, according to the article, this
problem does not effect OpenBSD or NetBSD.
Re:Does not effect OpenBSD or NetBSD (Score:3, Informative)
Re:Does not effect OpenBSD or NetBSD (Score:2)
If you have ever used these systems and configured kernels on these systems you would see similarities, but you would also see many more differences in kernel config parameters. The sound systems are different. FreeBSD is now using ipfirewall instead of pushing ipfilter like NetBSD and OpenBSD has a different packetfiltering mechanism.
They are not as similar as they used to be.
Re:Does not affect OpenBSD or NetBSD (Score:5, Informative)
Where in the story posting does it say that involves NetBSD and/or OpenBSD? It states clearly that it's a FreeBSD bug. And one that's already fixed in CVS to boot.
Re:Does not effect OpenBSD or NetBSD (Score:5, Funny)
I repeat, the OS/2 Warp kernel is not effected!
Re:Does not effect OpenBSD or NetBSD (Score:1)
*wipes coffee that was first in my mouth from screen*
Thanks...
Re:Of course the OS/2 wasn't effected! (Score:2)
The most enjoyable part of the whole topic is the fact that you corrected me, and you couldn't be more wrong if you tried.
Affected
1 : INCLINED, DISPOSED
2 a : given to affectation b : assumed artificially or falsely : PRETENDED
So tell me Captain English, which of those is the correct definition? According to m-w.com:
usage The confusion of the verbs affect and effect is not only quite common but has a long history. Effect was used in place of affect as early as 1494. If you think you want to use the verb effect but are not certain, check the definitions in this dictionary. The noun affect is sometimes mistakenly used for effect. Except when your topic is psychology, you will seldom need the noun affect.
So unless you thought I meant that the exploit had great fondness for OS/2, I stand uncorrected.
Re:Of course the OS/2 wasn't effected! (Score:2)
From dictionary.com [reference.com], definition 1 of affect: "To have an influence on or effect a change in."
Also from dictionary.com [reference.com], effect as a verb means "To produce, as a cause or agent; to cause to be." or "To bring to pass; to execute; to enforce; to achieve; to accomplish."
The leak isn't producing, executing, enforcing, achieving, or accomplishing FreeBSD. It is, however, having an influence or effect on FreeBSD.
So, your grammar argument is completely wrong. Technically, however, your original sentence isn't completely wrong because the bug does not effect OS/2. In this context, you really meant that is does not affect OS/2.
Re:Of course the OS/2 wasn't effected! (Score:1)
Re:Does not effect OpenBSD or NetBSD (Score:2)
Re:Does not effect OpenBSD or NetBSD (Score:2)
Check your dictionary, "effect" and "affect" are both transitive verbs as well as nouns.
Chris
Re:Does not effect OpenBSD or NetBSD (Score:1)
Re:Zealots... (Score:3, Interesting)
Re:Zealots... (Score:1)
cd
ls *dontuse*
linux-2.4.11-dontuse.tar.bz2
linux-2.4.11-dontuse.tar.gz.sign
patch-2.4.11-dontuse.gz
linux-2.4.11-dontuse.tar.bz2.sign
patch-2.4.11-dontuse.bz2
patch-2.4.11-dontuse.gz.sign
linux-2.4.11-dontuse.tar.gz
patch-2.4.11-dontuse.bz2.sign
So what!? Linux has had worse kernel bugs, IMHO. My FreeBSD box might be locally exploited. Anyone that rebooted their 2.4.11 Linux systems trashed any mounted filesystem.
Re:Zealots... (Score:1)
Linux distributions only include a kernel that has been tested by the distribution builder. The people that got bit in the ass are the ones that follow the Linux Kernel Mailing List and grab new releases. The reason they follow and install bleeding edge kernels is so that they can test them out en masse for Linus and friends, and they expect to wreck thier system. That's how the linux kernel development works.
Read the disclaimers for FreeBSD-5 previews and RC's - it's remarkably similar.
Re:Slashdot hype linkdumping at your service (Score:1, Informative)
Re:Slashdot hype linkdumping at your service (Score:1)
Re:Slashdot hype linkdumping at your service (Score:4, Insightful)
Re:Slashdot hype linkdumping at your service (Score:2)
If you're using 5.0RC2 you've got to figure there'll be some bugs.
Re:Slashdot hype linkdumping at your service (Score:1)
I think you are.
The security advisory says that branches RELENG_4 (up to 11 November 2002), RELENG_4_7, and RELENG_4_6 (both till 6 January 2003) contain the bug. I'd post the appropriate parts from the advisory, but the lameness filter thinks that I'm posting "junk" characters...sigh...
-Charles
Re:Slashdot hype linkdumping at your service (Score:1)
5.0 may or may not be affected - I would assume the former, but I may be wrong.
For more information on -CURRENT and -STABLE [freebsd.org]...
Re:Who cares? (Score:1)
Re:Who cares? (Score:1)
Key Phrase (Score:3, Insightful)
I love open-source.
Re:Key Phrase (Score:3, Interesting)
I love open-source.
Indeed.
I use FreeBSD_STABLE, I cvsup and recompile once a month. As the STABLE branch is "not vulnerable after 20021111" I'm happy to say I'd closed this particular hole 2 weeks before the FreeBSD authorities team had been informed of it's existance.
Agreed... (Score:1)
The problem is already fixed, and people just need to update themselves now.
-1, Too Subtle (Score:1)
thanks, and please ignore the jerks (Score:4, Insightful)
every time there is a mention of linux or xBSD or whatever OS having a problem, people who don't use it come out of the woodwork to say "LOOK! It sucks! It's broken! HaHaHa! We Win!".
how old are you people ? (mentally?)
no wonder why other tech-based sites have no respect for slashdot discussions.
Re:thanks, and please ignore the jerks (Score:2)
why would you be reading and posting here? (Score:1)
> no wonder why other tech-based sites have no respect for slashdot discussions.
I'd say that that's what's so great about slashdot, its egalitarian nature. Sure, you see many stupid posts (you might say that this post is stupid as well), but the fact that anyone can contribute to slashdot makes this place magical and dynamic; stupid posts are just a minor consequence. And let me ask you; if you think that slashdot is just a morons and idiots get-together, why would you be reading and posting here?
I wish NT kernel would leak (Score:1, Funny)
Rackspace (Score:1, Troll)
To this day, I do not know why they said FreeBSD is insecure at the Kernel.
Re:Rackspace (Score:1)
Re:Rackspace (Score:1)
Re:Rackspace (Score:5, Informative)
Not exactly a reprasentative poll but...
I use FreeBSD. I work in an office with 7 other people who all use RedHat. Out of the 8 of us, over the past 2 years, I'm the only one never to have been hacked.
The job I had before this was with an ISP which used FreeBSD for all their core systems. And in their whole history they had only ever had one FreeBSD system hacked, and that turned out to be an ex-employee who had added his public key to someobody elses authorized_keys file.
Re:Rackspace (Score:3, Informative)
Re:Rackspace (Score:3, Interesting)
The less cynical interpretation is that they don't have the support smarts to support FBSD.
The cynic in me suggests they have a deal with Red Hat.
Re:Rackspace (Score:2)
what kind of deal would they have? Something like if Rackspace exclusively uses Redhat, then Rackspace gets free versions of Redhat Linux with full access to the source code?
Re:Rackspace (Score:2)
what kind of deal would they have?
Cheap support? Millinary vouchers? Penguin guano scrapers?
Re:Rackspace (Score:1)
What's the point? (Score:3, Insightful)
"Ho hum. Another slow news day. Let's roll some dice and post a minor random security advisory from some random project and pretend it's news."
In case you didn't figure it out from the article (Score:5, Informative)
This is a local vulnerability; it doesn't, in and of itself, make servers vulnerable. Even if someone has a local account on a system, it takes hours of CPU time to perform an exploit.
It looks like the bug (and the fix) were already announced (and committed to CVS) but that the possibility of using the bug in an exploit was not revealed until now (and might not even have been appreciated by the original reporter).
Re:In case you didn't figure it out from the artic (Score:1)
Begin_Rant
Too much wah wah FreeBSD, Not OPEN or NET blather to give people, who may need direction and are unfamiliar, the proper support and information they deserve --hats off to you for pointing the truth out.
Afterall, it's the community spirit being fostered by the BSD and Linux and Open Source Movements that needs to be agressively passed along to the newly initiated cause we all know....
The DOCUMENTATION SUCKS, so the community needs to make up for it, or we'll all have Borg implants, M$ alarm clocks that don't wake us up for work, microwave ovens that can't cook a decent buttered popcorn, and Oracle poptarts that are still cold out of the toaster.
Having a choice makes up for small road block which are already fixed and gone.
Surely some people have a few production servers will probably need to be patched against this due to the service that they provide, but the odds that they'll get caught with their asses hanging out are slim to none and even the slightest of process monitoring would smell that in a hearbeat.
Any OS needs help out of the box and takes a clear and goal oriented approach to make it secure and tuned in any sense to the mold in which you want it to fit.
Too bad people would rather speak than what consider what people may want to hear....It obscures the point. I think the post meant well, but was the starting point of a degraded dialogue (minus my $0.02 of course
End_Rant
-Quillsta
Re:In case you didn't figure it out from the artic (Score:2)
Re:In case you didn't figure it out from the artic (Score:3, Informative)
The problem isn't calling just calling fpathconf() repetitively. The problem is calling fpathconf() repetitively on a socket or other non-file (which would be a bug in itself). And by "repetitively" I mean at least 2,147,483,648 times on the same file descriptor for a system panic exploit, and exactly 4,294,967,295 times on the same file descriptor (followed by a close()) for the priviledge escalation exploit.
No network daemon that is part of the FreeBSD base system can be coerced into performing the necessary actions. Grep the source tree yourself (you'll only get a handful of hits) and examine the resulting files if you don't believe me. It's impossible to rule out everything in the ports collection (and the FreeBSD folks are careful not to make any claims regarding them) but it's hard to imagine creating an exploit of greater than theoretical importance using any network server.
Re:FREEBSD IS DYING (Score:1)
FreeBSD is dyeing (Score:1)
Maybe the most interesting bit is... (Score:1)
> before by Nakamura Takayuki its impact
> was severely underestimated.
As someone noticed before, it looks like a known bug, but until now nobody has really done the check, "hey, what this bug does?".
Maybe now the FreeBSD Core team knows why they fixed the bug