Multiple Vulnerabilities in OpenSSL 274
gfilion writes "Updated versions of OpenSSL are now available which correct two security issues: A null-pointer assignment during SSL handshake and an out-of-bounds read that affects Kerberos ciphersuites. Full advisory available on OpenSSL site and US-CERT."
before the trolls start... (Score:4, Insightful)
Also I think this is a good news post simply because it helps to show we're not Anti-windows bias. We report security problems on ALL os's.
Oh well, sometimes you just have to combat the trolls.
Re:Non-Exploitable Security DOS Exploit (Score:5, Insightful)
Re:Non-Exploitable Security DOS Exploit (Score:5, Insightful)
cvs, make and build sure.. But when it's click windows update, somehow it's some monumental task thats just the worst thing imaginable.
Re:Let's be like M$... (Score:5, Insightful)
It's fairly reasonable to assume that the developers knew of the vulnerability some time before the new version became available.
I think it's good practice to do this if you can develop the new version fast enough. Announcing it early is only inviting someone to exploit it. I doubt anyone will fix the vulnerability themselves and put it into production before the official release comes out.
Re:Non-Exploitable Security DOS Exploit (Score:5, Insightful)
Yes. Most of us are not on the FreeBSD mailing list. Instead we wait for the more mainstream outlets like
Old news (Score:3, Insightful)
Re:Why Is This Happening? (Score:3, Insightful)
Re:Non-Exploitable Security DOS Exploit (Score:2, Insightful)
Get a life.
Re:Patch updates are NOT news (Score:2, Insightful)
Until someone roots the Gentoo servers....
Re:Non-Exploitable Security DOS Exploit (Score:5, Insightful)
One noteworthy difference, however, is that none of the BSD or GNU/Linux update methods tell the vendor the software (and their versions) that you run [petri.co.il]. To their credit, at least, none of them (including Microsoft) collect any actual personally identifiable information.
Yawn (Score:4, Insightful)
Rule #1: Unsafe data should be handled in sandboxed languages.
Rule #2: Programs that are exposed to unsafe data (server processes) should run at some minimum and constrained privilege level, not as root. The "must be root to bind to ports less than 1024" rule on Unix is almost exactly the opposite of what the rule should be.
I'm sure many people who don't understand these issues will flame me or say I am trolling, but oh well, someone needs to keep bringing this up until it sinks in.
------------
Create a WAP server [chiralsoftware.net]
advice on cvsup (Score:4, Insightful)
There is a minimal cvsup config for FreeBSD 4.9 - cvsup -g -L 2 and you're off and running.
*default host=cvsup6.FreeBSD.org
*default base=/usr
*default prefix=/usr
# The following line is for 4-stable. If you want 3-stable or 2.2-stable,
# change "RELENG_4" to "RELENG_3" or "RELENG_2_2" respectively.
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
# If your network link is a T1 or faster, comment out the following line.
*default compress
src-all
#ports-all tag=.
make buildworld & make installworld install *world*, which does not include anything you built out of
FreeBSD *is* intimidating at first, but if you take the thirty days of pain at the end of that time you'll be looking at your Linux boxes and wondering why you ever put up with the chaos
Re:Yawn (Score:3, Insightful)
People like you who don't understand that any software written in any language can be exploited should be shot. Your post is just painful to read.
Rule #1 is actually: VALIDATE ALL USER INPUT
This holds true for any language, c, java, php, brainfuck, or anything else. You can just as easily exploit a php script to insert sql statements and destroy a database as you could write code to crash a server using openssl assumeing the target apps do poor validation and you (the attacker) know what you're doing.
Many things that communicate over the are safely handled in c, java, php, etc etc because they are written to validate the input given to them and never do operations on data that hasn't been validated. You can write a secure implementation of openssl in c or java, it doesn't matter as long as the underlieing methods include validating all of your input.
This is another bullshit rule, if you have an app that properly validates all of its data then you can run the process with any level of permissions and not worry. The problem is, most apps aren't written with the idea to validate everything (the number one reason is because it adds overhead). Apps like openssl are written by more than one developer so its even harder to make sure everything is validated properly because of differing programming styles and methods, etc etc.
You *are* trolling.
Re:Non-Exploitable Security DOS Exploit (Score:5, Insightful)
Yes, lets just wait till some kiddie write a worm that crashes thousands servers all over the world and then post about it.
I like that slashdot posts security problems. Why?
1. For the lazy admin. Theres lot of them.
2. because its important to keep reinforcing the idea that computers suck (I dont care what OS you like) and need constant care.
Re:Yawn (Score:3, Insightful)
Rule #2: Ever heard of "bind to port and then change uid"?
I'm sure many people who don't understand these issues will flame me or say I am trolling, but oh well, someone needs to keep bringing this up until it sinks in.
Thanks for enlightening us all.
Re:Yawn (Score:4, Insightful)
Re:Yawn (Score:3, Insightful)
Openssl is coded in highly optimized C, with many components in assembly, and its still considered a high-overhead resource hog and is often the target of hardware acceleration.
If you seriously think "Java" is even in the running for that workload- then you are seriously deluded. VM's have this peculiar BIG problem: they are slow and resource-intensive. They dont play well with other processes, they cannot swap out to share ram, and they encourage memory bloat.
If anyone seriously wanted to use a programming language as a tool that lets you hide memory allocation and validate input- then they could choose C++. Java, et al, is just not a serious option.
Re:Open source isn't a perfect model for secure co (Score:1, Insightful)
What's the difference you ask?
Closed source software M is found to have a bug, and that hole is open for 6 months; Open Source software S is found to have a bug, but the hole is open for 2 weeks MAXIMUM, most of the time it's fixed and patches available within 1 week.
Thus, Open Source is more secure because holes, which are, to a certain extent, inevitable, remain open for a very short amount of time, and on the whole not long enough to exploit.
C language is (also) to blame. (Score:4, Insightful)
A null-pointer assignment
an out-of-bounds read
Aside from the programmer's errors, if C was safer, both bugs would have already been caught a long time ago. C is clearly to blame here.
Re:Yawn (Score:3, Insightful)
Funny, then why have the qmail [cr.yp.to] and djbdns [cr.yp.to] security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?
Re:Non-Exploitable Security DOS Exploit (Score:3, Insightful)
Oh... that's MUCH easier than Windows Update. Can't wait for my mom to try doing this...
</asbestos suit>