httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <>
Subject Re: half-OT: heartbleed CVE-2014-0160
Date Wed, 09 Apr 2014 20:30:40 GMT

Am 09.04.2014 21:42, schrieb Rainer Jung:
> On 09.04.2014 18:05, Reindl Harald wrote:
>> Am 09.04.2014 17:41, schrieb William A. Rowe Jr.:
>>> Combined with typical ssl session shmcb ... That single process still has session
keys of other prefork processes,
>>> as well as the common ssl session ticket key and ssl cert keys.  In practice
the benefits of prefork are somewhat
>>> limited to casual attacks.
>> that's clear and anything related to SSL/TLS (certificates, keys)
>> needs to be changed, the original question was about user-payload
>> like passwords submitted via POST on the neighbour worker
> But how do you know it is only the neighbour worker?

not the - any neighbour worker

i am still not 100% sure that in case of httpd-worker "only"
certs and keys are compromised while at the same time i
don't want to spread panic around me

> If the memory hasn't been cleared, the next connection from the attacker
> could get handled by the previous neighbour and confidential data might
> still sit in that processes memory readable by the attacker.

that sounds bad - i had the impression that physical memory and
memory assigned to a process from previous requests is somehow
different - now it sounds like a nightmare

> What I didn't check until now, is whether one can describe the
> places/addresses in memory that are readable by an attacker (any address
> or only 64KB around an address at some fixed position in some request or
> connection handling struct) and whether we could for some platforms then
> describe the real exposure. Some data might always be to far away (very
> different address). Not sure whether that's feasible or the answer is
> simply "any address"

so if i understand that correctly better be safe than sorry it would
be a good adivse to inform all users that it is unlikely but possibly
anyways a good idea to recommend change *any* passwords used in the
history independent if multi-threaded or mpm-woker was used?

until know i was more or less convinced that in case of mpm-worker
and changed all certs / private keys yesterday the problem is
isolated - well, that issue is terrible at all :-(

however, thanks for feedback, i think we should activly recommend
to change *any* credentials used in the past to be sure and prevent
"why nobody told me" from users / customers in the future

View raw message