But he wrote an RFC that said you MUST test the length, then wrote code that didn't test the length, then you expect him to provide a test case for that?
If they had resorted to their area of expertise and simply used the malloc provided with the system, like all the regular chaps would do, even in their situation, the code would crash upon running (freed memory access) and the bug would surface already at New Years Eve 2012-2013 when Seggelmann was hopefully test-running it.
Only if Seggelman thought to test it with a malformed packet.
If the code was run with a malloc that splattered unmapped pages around like OpenBSD malloc apparently does then it would crash when it was exploited, and people would be complaining "OpenBSD breaks OpenSSL, fix your shit Theo" and the problem would have been found earlier.
The bad bit is that "amt" is not checked against "packet->len", so the copy into "buffer" reads off the end of the allocated data structure "packet". The data read may be freed memory, or it may be allocated memory.
The only way malloc could completely protect against the bug would be by putting an unmapped guard page after every malloced block - making every malloced block at least one page long and slowing malloc down by the time needed for all those munmaps. (Probably making malloc slow enough to incite OpenSSL devs to implement their own malloc layer...)
I think the real bug is in the RFC.
Look at the fix:
/* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length)
return 0;/* silently discard */ hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0;/* silently discard per RFC 6520 sec. 4 */ pl = p;
Why does the heartbeat request even contain the length of the heartbeat block? We know the length of the SSL record!
(Not even bothering with the whole problem that the heartbeat thing is ridiculous - there are already ways of keeping connections alive at the TCP level - why does every layer of the protocol need it's own keepalive).
That is, if they were aware that OpenBSD's malloc() contained code to ensure against data leakage, it would seem to me to be highly probable they would have implemented the same deal in OpenSSL given, you know, their entire point is security. The fact they didn't makes me think they didn't know OpenBSD's malloc() had these measures in the first place.
Not just OpenBSD's malloc(). glibc can do the same thing if you set MALLOC_PERTURB.
Yup, tyranny by negociation beteween workers and bosses representatives. Terrible.
The way much labour law in France goes, including this case, is the law says: work it out among yourselves, and providing it fits in with existing law that's the way we'll do it.
Seriously, if someone wants to work crazy hours, why not let them?
Nothing stopping you.
All this says is the boss can't fire you for not replying to his out-of-hours email.
(Previously, he might have made an attempt to accuse you of "faut grave", a grave dereliction of duty, which could get you fired without unemployment insurance).
Which possibly explain her total misunderstanding of a deal made between the unions and representatives of management (not a law), which is that bosses aren't allowed to hold workers refusal to handle work related mail outside of working hours against them.
There is nothing preventing someone from replying to the boss at 23:59, but if they don't the boss can't bitch.
Slashdot Mirror
one of the interesting things about this outbreak is that it is close to the Tai forest in Cote d'Ivoire, so we can guess where it came from.
Except that it turns out not to be that strain, it's similar to the strains found in the RDC, 2500 kilometers away.
How does a disease move 2500 kilometers in less than 14 days?
Good point.
But he wrote an RFC that said you MUST test the length, then wrote code that didn't test the length, then you expect him to provide a test case for that?
If they had resorted to their area of expertise and simply used the malloc provided with the system, like all the regular chaps would do, even in their situation, the code would crash upon running (freed memory access) and the bug would surface already at New Years Eve 2012-2013 when Seggelmann was hopefully test-running it.
Only if Seggelman thought to test it with a malformed packet.
If the code was run with a malloc that splattered unmapped pages around like OpenBSD malloc apparently does then it would crash when it was exploited, and people would be complaining "OpenBSD breaks OpenSSL, fix your shit Theo" and the problem would have been found earlier.
I know this is redundant but this is funny:
Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.'
https://tools.ietf.org/html/rfc6520
Internet Engineering Task Force (IETF)
Request for Comments: 6520
Category: Standards Track
ISSN: 2070-1721
R. Seggelmann, M. Tuexen: Muenster Univ. of Appl. Sciences
M. Williams: GWhiz Arts & Sciences
February 2012
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension ...
If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.
Can't even implement an RFC he wrote himself. Nice one.
considering that the real bug is OpenSSL's malloc, where it was reusing 'freed' memory I think that's the bug that is critical.
Well. no.
The bad bit of code is, per http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf:
struct {
unsigned short len;
char payload[];
} *packet;
packet = malloc(amt);
read(s, packet, amt);
buffer = malloc(packet->len);
memcpy(buffer, packet->payload, packet->len);
write(s, buffer, packet->len);
The bad bit is that "amt" is not checked against "packet->len", so the copy into "buffer" reads off the end of the allocated data structure "packet". The data read may be freed memory, or it may be allocated memory.
The only way malloc could completely protect against the bug would be by putting an unmapped guard page after every malloced block - making every malloced block at least one page long and slowing malloc down by the time needed for all those munmaps. (Probably making malloc slow enough to incite OpenSSL devs to implement their own malloc layer...)
I think the real bug is in the RFC.
Look at the fix:
if (1 + 2 + 16 > s->s3->rrec.length)
return 0;
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0;
pl = p;
Why does the heartbeat request even contain the length of the heartbeat block? We know the length of the SSL record!
(Not even bothering with the whole problem that the heartbeat thing is ridiculous - there are already ways of keeping connections alive at the TCP level - why does every layer of the protocol need it's own keepalive).
Worth it for me.
YMMV.
Oh, and read this: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
In effect at some points OpenSSL does:
free (rec);
rec = malloc (...);
and assumes that rec is the same.
Eeew,
That is, if they were aware that OpenBSD's malloc() contained code to ensure against data leakage, it would seem to me to be highly probable they would have implemented the same deal in OpenSSL given, you know, their entire point is security. The fact they didn't makes me think they didn't know OpenBSD's malloc() had these measures in the first place.
Not just OpenBSD's malloc(). glibc can do the same thing if you set MALLOC_PERTURB.
I am my manager.
Small company.
Zow, if you're sending an email to someone at home in bed because the hospital has lost power...
Let me explain the concept of "the night shift" and "on call" to you...
Yup, tyranny by negociation beteween workers and bosses representatives. Terrible.
The way much labour law in France goes, including this case, is the law says: work it out among yourselves, and providing it fits in with existing law that's the way we'll do it.
Or perhaps la vie fade (dolce has a wide range of meaning).
The "boring, unseasoned, tasteless life"?
Zow, that's a weird translation.
"La dolce vita" (the film) was released in France as "La Douceur de vivre".
Douceur: softness/sweetness/gentleness/smoothness
Well this agreement is actualy only for "management".
Of course it doesn't apply to people "on call", as long as "on call" is limited to a certain number of days/year.
And it's only a limit on what you can be required to do, it doesn't limit what you can do of your own free will.
(A page every six months. You lucky bastard. I dream of only getting a page once every six months).
No, what this not-a-law does is makes it harder for your boss to sack you for not doing work outside working hours.
If you want to try and climb the slippery pole by brownnosing, feel free.
It's 4:30 over there. Quit'n time. You'll have to wait until 9am tomorrow before anyone over there is allowed to answer.
You're thinking of Germany, not France.
We tend to quit around 18:30.
Seriously, if someone wants to work crazy hours, why not let them?
Nothing stopping you.
All this says is the boss can't fire you for not replying to his out-of-hours email.
(Previously, he might have made an attempt to accuse you of "faut grave", a grave dereliction of duty, which could get you fired without unemployment insurance).
France fails at having an Internationally competitive workforce.
Don't be ridiculous, France has one of the most productive workforces in the world (in GDP/worker and GDP/hour worked).
Yup, that's why Mangan writes:
whatever the French call la dolce vita
She's making a joke about her poor French skills.
Which possibly explain her total misunderstanding of a deal made between the unions and representatives of management (not a law), which is that bosses aren't allowed to hold workers refusal to handle work related mail outside of working hours against them.
There is nothing preventing someone from replying to the boss at 23:59, but if they don't the boss can't bitch.
Clone a man from a woman? Pretty hard. Do it the other way round, a Y chromosone is just a damaged X.
Write your code in Perl with taint checking on.
1/2 joke.
If someone is using an ancient openssl library (0.9.8) they have nothing to worry about. The problem was introduced in 1.0.0
Funny, this is the one slashdot story I've seen where the AC's make more sense than the registered users.
Thanks, that sounds much less like bollocks than I thought.
It is made of quarks, it's "just" that it doesn't seem to be a meson (quark +antiquark) or a baryon (3 quarks)
They're speculating that it's charm + anticharm + up + antidown, i.e 4 quarks (or 2 quark/antiquark pairs).
Probably bollocks.
Sounds like a silly story.
Almost as unbelievable as throwing one of the founders of the JPL out of the country because he's "obviously" a commie spy, only to have him create the whole chinese space program