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
signature.asc
Description: OpenPGP digital signature
