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

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.

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

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