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? 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. 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". Regards, Rainer
