Fzero
Advanced Member
- Joined
- Mar 9, 2010
- Messages
- 4,702
Just if any of you might need to be aware of this and not read about it already
http://heartbleed.com
http://heartbleed.com
Heartbleed bug
- Thread starter Fzero
- Start date
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
The question I keep asking is what the hell are raw passwords doing being kept around in memory.
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Pandora is running version 0.9.8. The bug was introduced with 1.0.1. We're fine in that regard.
- Joined
- Jan 18, 2010
- Messages
- 11,409
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Why? The bug has been fixed.
Well, the modus operandi of an encrypted connection is that you have cleartext on the client side, the whole cleartext is encrypted before it is sent over the secure connection, and then the encrypted message is decrypted again on the receiving side. It might be possible to encrypt the passwords alone on the client side before doing the secure connection bit, but that would mean trusting your security to the individual browsers javascript engines - and you really don't want that - and anyways, noone has seen the need since the TLS connection is encrypted and secure anyway. But of course the serverside will have the decrypted messages in working memory. As well as everything else - This is a huge, huge hole, where anybody who knew about the exploit could pick anything from the servers memory at will.
To quote Bruce Schneier: On a scale from 1 to 10, this is an 11.
Magic Sam
Forever Homebrew
Because some of these implementations provide interesting features for the Pandora (IMHO):
CyaSSL (wolfSSL):
MatrixSSL:
PolarSSL:
Just sayin'
Cheers, Magic Sam
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Fair enough. Has nothing to do with the bug though
Mr_Loon
Can't Remember
- Joined
- Aug 30, 2010
- Messages
- 2,332
So will anyone here be changing their passwords because of this?
The linked article seems like a case of scaremongering from the Beeb especially in lieu of the last paragraph of said article.
This and a few other things make me think that some kind of biometric security needs to replace / at the very least augment passwords ASAP.
The linked article seems like a case of scaremongering from the Beeb especially in lieu of the last paragraph of said article.
This and a few other things make me think that some kind of biometric security needs to replace / at the very least augment passwords ASAP.
Attackers would then steal the biometric data, assuming an exploit like this occurs again.
I think the issue here is the lack of separation of data coming from different clients on the server side. A server which forks a new process for each new client connection wouldn't suffer from the same issue (I think). But such a server would probably have horrible performance.
Last edited by a moderator:
fusion_power
Advanced Member
I really start to wonder, is there anything really SAFE today? Super-Idiot-Proof-Unbreakable-Safe so we don't have to change our passwords basicly every week because "safe" things were cracked/stolen/fished etc.? It really get's annoying.
I'm sure, the person who invents a 100% safe, uncrackable, unexploitable password system would get an Nobel Price... and the attention of the NSA.
Super-Idiot-Proof-Unbreakable-Safe so we don't have to change our passwords basicly every week because "safe" things were cracked/stolen/fished etc.? It really get's annoying.I'm sure, the person who invents a 100% safe, uncrackable, unexploitable password system would get an Nobel Price... and the attention of the NSA.
levi
Still fresh, damnit!
GPGing stuff locally then putting it on t'internet is still pretty secure. Or, as XKCD noted, pen and paper works too.
Not sure whether process separation would work, @Yoyobuae. Even if you can't provide the correct password, the process needs to compare the one you enter against the one stored. Course, it should one-way encrypt your entered password first and compare that against a pre-prepared encryption of the recorded password without actually loading the password (and having it in a separate database to be sure), but I don't know of anyone going to that effort to keep their memory secure. Especially against an OpenSSL bug - you worry about buffer overflows in your own code, but OpenSSL was *legendary*.
Not sure whether process separation would work, @Yoyobuae. Even if you can't provide the correct password, the process needs to compare the one you enter against the one stored. Course, it should one-way encrypt your entered password first and compare that against a pre-prepared encryption of the recorded password without actually loading the password (and having it in a separate database to be sure), but I don't know of anyone going to that effort to keep their memory secure. Especially against an OpenSSL bug - you worry about buffer overflows in your own code, but OpenSSL was *legendary*.
Hồng Thất Công
Đả Cẩu Bổng Pháp
Easy. Just get rid of all computers and the internet and just use Pandora and PyraI really start to wonder, is there anything really SAFE today?
levi
Still fresh, damnit!
And keep on our version of Angstrom, which hopefully has had all the bugs knocked out of it (though how far back some of these recent SSL bugs suggest there could still be bugs that far back). Debian got hit by this bug (and the GnuTLS one too) just like everyone else.
Passwords are usually stored as hashes anyway. Hashes of weak passwords could be potentially broken, though.
Anyway, that still a big improvement compared to leaking sensitive data from other users.
Maybe there is a way to isolate data within the same process, without taking a huge performance hit. Like a sandbox of sorts.
Last edited by a moderator:
levi
Still fresh, damnit!
Ah, I'd heard of password hashes before (and indeed wrote that first before changing it to 'password encryption'), but evidently never looked them up. I was familiar with traditional hashes, where you generally hash something long into a shorter hash key for speed of look-up, where you will occasionally, but commonly enough, have to deal with hash collisions. A cryptographic password hash on the other hand hashes a password to a longish digest, which is much less likely to suffer from collisions. Due to the use of clever crypto in generating the digest, is practically impossible to engineer one using today's technology too.
Good job I've never had to code a password system then.
As for sandboxing within a process, that would require fairly raidcal rework of the OS I think. The process boundary is the traditional sandbox, and threads within a process can all see each others memory IIRC. The traditional solution is two separate processes and IPC, generally asynchronous, which can be fairly slow for single uses but tends to scale okay.
That said, assuming people are not storing passwords as plaintext in these compromised systems, the only avenue for attack I can see is observing people logging in at the same time as your attack, as even if you do manage to grab the password database of digests, they aren't any use to you unless you go on to rewrite the server code using a buffer overrun somewhere, which sounds like an awful lot of work to me. So it's a matter of the web servers configuration - from a quick search it seems Apache can be configured to create one process per connection, but it isn't generally run like that cos that really doesn't scale at all well.
So perhaps what's needed instead is some bottleneck in password entry and verification, such that a single process handles responding to the login request, hashing the password and checking that against the database, then overwriting the password in memory before responding to the next request. Granted that process is going to be very busy if everyone tried to log in at once, and I assume it's not possible to configure a web server of today to use an external process to serve a specific POST request without even parsing any of the request arguments itself.
Or perhaps if you could design the website to use a separate page for logging in, rather than having a login box at the top of every page, the server could know to farm off a separate process for each occurrence of a request for that page which will stay active long enough to handle the form submission and set the appropriate 'logged in' session cookie. It'd then have to terminate, to avoid overclogging the system with processes, which might be tricky, but at least then you don't have to write your own HTTP server.
Unless of course the session cookie is another avenue of attack, which perhaps it is. Though that wouldn't require everyone to change their passwords - just invalidate all current session cookies. And anyway, this post is already monstrously long enough to leave consideration of that for another day.
Good job I've never had to code a password system then.
As for sandboxing within a process, that would require fairly raidcal rework of the OS I think. The process boundary is the traditional sandbox, and threads within a process can all see each others memory IIRC. The traditional solution is two separate processes and IPC, generally asynchronous, which can be fairly slow for single uses but tends to scale okay.
That said, assuming people are not storing passwords as plaintext in these compromised systems, the only avenue for attack I can see is observing people logging in at the same time as your attack, as even if you do manage to grab the password database of digests, they aren't any use to you unless you go on to rewrite the server code using a buffer overrun somewhere, which sounds like an awful lot of work to me. So it's a matter of the web servers configuration - from a quick search it seems Apache can be configured to create one process per connection, but it isn't generally run like that cos that really doesn't scale at all well.
So perhaps what's needed instead is some bottleneck in password entry and verification, such that a single process handles responding to the login request, hashing the password and checking that against the database, then overwriting the password in memory before responding to the next request. Granted that process is going to be very busy if everyone tried to log in at once, and I assume it's not possible to configure a web server of today to use an external process to serve a specific POST request without even parsing any of the request arguments itself.
Or perhaps if you could design the website to use a separate page for logging in, rather than having a login box at the top of every page, the server could know to farm off a separate process for each occurrence of a request for that page which will stay active long enough to handle the form submission and set the appropriate 'logged in' session cookie. It'd then have to terminate, to avoid overclogging the system with processes, which might be tricky, but at least then you don't have to write your own HTTP server.
Unless of course the session cookie is another avenue of attack, which perhaps it is. Though that wouldn't require everyone to change their passwords - just invalidate all current session cookies. And anyway, this post is already monstrously long enough to leave consideration of that for another day.
The people who should do something ASAP isn't ordinary users - It is server admins. The big catch isn't individual users passwords, but the servers key pairs and certificate. With that, any malicious intruder can mount a man-in-the-middle without even having to do SSL-strip or anything like that.
For good info and links: https://www.schneier.com/blog/archives/2014/04/heartbleed.html
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
To be fair, if you need a password system and your first thought is "I can code this myself" then you're doing something wrong. You're usually better off using one of the many solutions that already exist than coding up your own dailywtf.
