FreeBSD security Advisories: FreeBSD-SA-03:09.sign 78
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."
Here's the text in case it gets /.'ed (Score:5, Informative)
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 (Score:5, Funny)
What, like the sys admins porn [slashdot.org] collection.
Bias in topic titles?? Never!! (Score:5, Funny)
Re:Bias in topic titles?? Never!! (Score:2, Informative)
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" (Score:5, Insightful)
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" (Score:1, Insightful)
freebsd-security mailing list (Score:5, Insightful)
Re:freebsd-security mailing list (Score:4, Insightful)
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 (Score:2, Informative)
Re:freebsd-security mailing list (Score:2)
Re:freebsd-security mailing list (Score:3, Funny)
Because if they reported the Linux SAs, even the SCO stories would be lost the the tidal wave.
Re:freebsd-security mailing list (Score:2)
Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:3, Interesting)
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)); (Score:3, Informative)
IOW, you do need to worry about this, and you do need to patch your system.
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:2)
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:1)
If you dont do your own, custom installs, yes...
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:3, Interesting)
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:4, Informative)
NO_MODULES= true # do not build modules with the kernel
line in
I don't build modules on my production machines, there is no need. This prevents that.
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:2)
Re:Malloc(sizeof(ram.total) - sizeof(ram.used)); (Score:2, Informative)
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 o
Re:What We Can Learn From BSD (Score:1)
"I dont hate Linux, just the most of the stupid kiddies who use it"
Binary patches... (Score:4, Informative)
See my sig for details.
Re:*BSD is dying (Score:1)
"I dont hate Linux, just the most of the stupid kiddies who use it"
Linux is dying (Score:1, Funny)
hot mail security flaw I knew it! (Score:3, Funny)
Re:BSD problems (Score:1)
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 (Score:1)
Re:BSD problems (Score:2)
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
Re:BSD problems (Score:1)