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.'

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.

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));

[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!

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: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

[adri]

Yay, you've been owned by a troll!