FreeBSD security Advisories: FreeBSD-SA-03:09.sign

Dan writes "FreeBSD security team has released two new advisories. The first advisory entitled "Insufficient range checking of signal numbers" could allow a malicious local user to use this vulnerability as a local denial-of-service attack. The second advisory "Kernel memory disclosure via ibcs2" could allow a malicious user to call the iBCS2 version of statfs(2) with an arbitrarily large length parameter, causing the kernel to return a large portion of kernel memory containing sensitive information."

Comments

Here's the text in case it gets /.'ed

[DrSkwid]

nah, who am I kidding

the signal thing is more than a D.O.S. though

However, in FreeBSD 5.x, the assertion code is not present if the
`INVARIANTS' kernel option is not used. In FreeBSD 5.0-RELEASE and
5.1-RELEASE, `INVARIANTS' is not enabled by default. In this
configuration, a malicious local user could use this vulnerability
to modify kernel memory, potentially leading to complete system
compromise. (FreeBSD 4.x is not vulnerable in this way.)

sensitive information

[patch-rustem]

... to return a large portion of kernel memory containing sensitive information.

What, like the sys admins porn collection.

Bias in topic titles?? Never!!

[Anonymous Coward]

It's sort of interesting that this FreeBSD vulnerability is headlined with such a cryptic title. Now, if it were a vulnerability in Windows, it would probably have been titled 'New Windows Exploit crushes small furry animals mercilessly.'

Windows Exploit ??News!? Never!!

[Anonymous Coward]

A new windows exploit would not get accepted as a news story.

Re:Bias in topic titles?? Never!!

[beefdart]

Its not like someone could throw up an ActiveX enabled webpage, and root your box.

The last few windows vulnerabilities have been a huge deal. Microsoft wouldnt bother to fix a hole this small unless someone made a worm for it.

"Malicious Local User"

[Farley Mullet]

If someone malicious has access to your computer, bad things can happen. It's good to see that the FreeBSD team is tightening things up, but the bottom line is that if someone has an account on a system and they're determined, they'll find a way to do some damage.

Re:"Malicious Local User"

[Anonymous Coward]

Given all the big changes they've been making to the kernel, I'm not surprised that they're encountering un-dotted i's and uncrossed t's. That's one of the reasons that OpenBSD is the BSD with the fewest new features apart from those related directly to improving security. Theo is fond of saying that new features create new security holes. I wouldn't be too hard on the folks at FreeBSD though. It is -current they're concentrating on, after all.

freebsd-security mailing list

[dodell]

Subscribe to this list, and you had this story about 12 hours ago. You also downloaded and updated your src tree and fixed the bug in a matter of a few minutes. Why is it that a FreeBSD SA makes it to this site and Linux SAs don't?

Re:freebsd-security mailing list

[zenyu]

Subscribe to this list, and you had this story about 12 hours ago. You also downloaded and updated your src tree and fixed the bug in a matter of a few minutes. Why is it that a FreeBSD SA makes it to this site and Linux SAs don't?

Prolly cuz the editor and poster were thinking of "only one remote security breach in the default configuration in seven years" OpenBSD. There are local user exploits found all the time in the Linux distros and in the BSDs, when remote vulnerabilities are found in any of them it usually does make it to /.

But yeah, I usually read about and check my system based on security advisories before it ever makes it to slashdot.. prolly everyone else does as well which explains the 12 hour lag.

Re:freebsd-security mailing list

[kernelistic]

It's interesting to note that you need to have shell access to do anything to the FreeBSD systems affected.

Re:freebsd-security mailing list

[Anonymous Coward]

Why is it that a FreeBSD SA makes it to this site and Linux SAs don't?

Because if they reported the Linux SAs, even the SCO stories would be lost the the tidal wave.

Re:freebsd-security mailing list

[ratfynk]

As to why, is obvious, and the fact that with MS you do not, will eventually kill most Win servers! MS knows this and is the reason why they are implimenting Paladium, or fritz chip solutions. Make everything that runs on windows servers have traceable and revokeable security certificates. The mother of all shoot yourself in the foot security measures. The next few years are going to be very interesting for free software as alot of important people, especially the big ISPs start to get really pissed at Microsoft! That is if some branch of MS doesn't devour them all first.

Re:freebsd-security mailing list

[Stephen Samuel]

Why is it that a FreeBSD SA makes it to this site and Linux SAs don't?

1. They're fighting to get one BSD story per day. This is today's story.
2. Like any news -- it's the unusaual that gets the attention. BSD SA's are unusual.
3. we wanted to get a rise out of you -- we succeeded.

Re:freebsd-security mailing list

[Anonymous Coward]

And why is that interesting?

Re:freebsd-security mailing list

[Anonymous Coward]

I haven't noticed any SAs for my C64 or AppleII, I guess that means they're the most secure (and therefore best) OS' around!

Malloc(sizeof(ram.total) - sizeof(ram.used));

[mnmn]

I wouldnt worry about ibcs, always compile a kernel without it(and other binary compatibilities) for real usage. The statfs problem looks real and worrisome though. We've seen too many of similar problems where a user grabs large memory and reads the sensitive data.

I wonder if a C-reading script could read all the source code and mark all the big mallocs/reallocs that users get access to.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[phoenix_rizzen]

One thing to note about FreeBSD: just because it isn't compiled into the kernel doesn't mean you don't have access to it. Almost everything that is not directly compiled into the kernel is compiled as a module. If you fire up an app that requires ibcs2 support, then the kernel will load the ibcs2.ko kernel module. Any problems with the ibcs2 subsystem will then be in your kernel.

IOW, you do need to worry about this, and you do need to patch your system.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[mnmn]

I custom-compile all kernels for the FreeBSD servers and remove everything I dont need, not even as 'option'. I also delete the old modules lying around. I like em lean.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[beefdart]

>Almost everything that is not directly compiled into the kernel is compiled as a module.

If you dont do your own, custom installs, yes...

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[phoenix_rizzen]

How does one disable the building of kernel modules? I've only ever seen the NO_MODULES_WITH_WORLD knob, but nothing to completely disable the building of modules.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[kernelistic]

Read the tunefs(8) and tuning(7) manpages.

Here's a list of things that you might want to try out:

- Rethink your slicing, see tuning(7) for more on this.
- Enable softupdates on the data filesystems of choice.
- Compile a custom kernel with only the drivers that you *really* need.
- Tune the VFS sysctls. This item cannot be stressed enough. The values selected depend upon the role of the server.
- Tune your IP stack. There's a number of sysctls that will quadruple your network throughput. Google has a number of guides which provide good insight.

Remember: Copying a file from a directory to another is by no means a scientific test, as it depends upon the layout of the disk, sector size, disk cache, and a laundry list of other variables. The output of bonnie++ is what you should use to benchmark your IO subsystem.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[Anonymous Coward]

Don't reply to this, it's a well-known and much-used troll. At least wait for the trolls with some signs of intelligence to reply. :)

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[ffsnjb]

uncomment the
NO_MODULES= true # do not build modules with the kernel

line in /etc/make.conf

I don't build modules on my production machines, there is no need. This prevents that.

Re:Malloc(sizeof(ram.total) - sizeof(ram.used));

[phoenix_rizzen]

Aha! Learn something new everyday. Thanks. (Don't know how I've missed that, considering how many times I've edited make.conf.)

Binary patches...

[cperciva]

Binary patches aren't available for these advisories yet, but they will be soon (ETA 12 hours?)

See my sig for details.

Re:*BSD is dying

[beefdart]

And posts like that prove Darwin wrong...

"I dont hate Linux, just the most of the stupid kiddies who use it"

Re:What We Can Learn From BSD

[beefdart]

And people like that prove Darwin wrong...

"I dont hate Linux, just the most of the stupid kiddies who use it"

hot mail security flaw I knew it!

[ratfynk]

Hmmm so let me get this straight, security flaw 2 send lots of requests to the hot mail server and get lots of core info back. So thats why Hot Mail works the way it does and all we get is spam!

Re:What We Can Learn From BSD

[bsd troll]

"I dont hate Linux, just the most of the stupid kiddies who use it"

Keep up the good fight, work on the grammar.

Linux is dying

[cozman69]

Linux is dead. Long live BSD.

Re:BSD problems

[beefdart]

Well first off, no one in there right mind would listen to what you have to say: "Even Emacs Lite is straining to keep up as I type this."
cause you use Emacs.

If you have half a brain there is no faster x86 OS than FreeBSD.

I am not an addict, I just use the best tool out there.

Re:New virus is hitting hard

[beefdart]

I hate people...

Re:BSD problems

[Anonymous Coward]

Are you gay or something?

Re:BSD problems

[Phactorial]

There wasn't. Now, there is. Please get a clue.

Re:BSD problems

[R.Caley]

I don't want to start a holy war here

Sure you don't.

[20 minutes + on a PIII 800 to copy a 17MB file]

Charitably, you have a machine which is seriously fucked up at the hardware level. Less charitably, you are making it up.

For comparison, PIII 500, old scavenged (ie slow) disks, 11 seconds to copy a 130MB file between disks, 18 seconds within one disk.

I have a policy of not tuning my systems, so this is about as slow as it is possible for FBSD to get, without underlying problems. I have no reason to think any of the other BSDs are significantly slower.

If you really have the problem you claim, I can only think you are either getting huge numbers of recoverable hardware disk errors, or something has eaten all your memory and the system is thrashing wildly.

Re:BSD problems

[Anonymous Coward]

[20 minutes + on a PIII 800 to copy a 17MB file]

Charitably, you have a machine which is seriously fucked up at the hardware level. Less charitably, you are making it up.

For comparison, PIII 500, old scavenged (ie slow) disks, 11 seconds to copy a 130MB file between disks, 18 seconds within one disk.

The last time he posted this, I thought it was over the network... but thats still an obscenely slow time even over 10Mbit. I've copied 1GB files off of my old laptop to my old P/166 (its now a P2/350) NetBSD server over 10Mbit *thinnet* and it took less than an hour. Now, admittedly, that was with no other real network traffic, but still... 20 minutes for 17MB?? I'd have to agree, *serious* network problems. Either that or he's quoting the time to send it between machines on a 100Kbit serial cable.

Re:BSD problems

[adri]

Yay, you've been owned by a troll!

Re:BSD problems

[Anonymous Coward]

If you really have the problem you claim, I can only think you are either getting huge numbers of recoverable hardware disk errors, or something has eaten all your memory and the system is thrashing wildly.

Heh, yeah.
I had a 300MHz AMD K6-2 with a 4GB Samsung disk that this problem. Thousands of recoverable disk errors. But it still only took about 2mins to copy a 100MB file from one part of the disk to another. I couldn't believe it actually kept working - had debian linux on the box with reiserfs but kept getting corrupted and would refuse to boot. fsck'ing wouldn't help so I blew it away and put FBSD 4.7 on it. Worked for a while until the disk stopped working altogether (wouldn't spin up).

Giving Credit where it is due.

[Anonymous Coward]

Silvio Cesare found this long ago, and the crack security team at FreeBSD *just* got around to doing an advisory. Here is the original finding
http://www.ruxcon.org/post-con/slides/a2. tgz

Re:*BSD wont work?

[Anonymous Coward]

I don't want to start a holy war here,

Your claims have already been answered the last time you posted.

Given you've reposted the same claim a 2nd time, you either can't understand English (or what passes for such on slashdot) or you ARE 'looking to start a holy war'.

Re:BSD problems

[Anonymous Coward]

Autotroll v0.1 ... just replace the various bits, and troll when ready.

--------------

I don't want to start a holy war here, but what is the deal with you <target system> fanatics? I've been sitting here at my freelance gig in front of a <target system> box (a <insanely fast high spec computer>) for about <very long time> now while it attempts to copy a <average size> file from one folder on the hard drive to another folder. <very long time>. At home, on my <old slow clunky computer>, which by all standards should be a lot slower than this <target system> box, the same operation would take about <very short time>. If that.

In addition, during this file transfer, <random program> will not work. And everything else has ground to a halt. Even <very resource-light program which should work fine> is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various <target system> machines, but suffice it to say there have been many, not the least of which is I've never seen a <target system> box that has run faster than its <troll's prefered system> counterpart, despite the <target system> machine's faster chip architecture. My <really really slow computer with crap specs> runs faster than this <insanely fast high spec computer> at times. From a productivity standpoint, I don't get how people can claim that <target system> is a "superior" machine.

<target system> addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a <target system> over other faster, cheaper, more stable systems.

--------------