I suppose to keep the password analogy together, people reuse passwords all the time, timing attacks exist, etc?
History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here.
Edit: Even the authors of this poc seem to agree with me https://depthfirst.com/research/nginx-rift-achieving-nginx-r...
Obviously you need to defend, that is quite generalization there. You need to prove how the vulnerability itself reduces the entropy of ASLR.
The authors don't really give support for that. They just say that they can brute-force it without crashing the whole Nginx. But they don't say how the entropy is reduced. They have zero information where the child process even starts, whether they hit the child, or if it even is the same child. So you should provide us technical and precise reasoning why it is not mitigating?
> You need to prove how the vulnerability itself reduces the entropy of ASLR
Not really? Looks like we have a controlled-length overflow on a fork-based server, a situation where ASLR is known to not be very useful.
It does not work like that - it has certain pre-condition requirements. You also need a reliable oracle which tells information when you actually hit the child process, whether child crashes and whether you are even in the same child. When you can retrieve this information, you are then removing re-randomization between attempts. That reduces the entropy, but it only helps if remaining search space is small enough. They don't show that they have oracle.
Additionally, for RCE, you need to find libc base and that is randomized alone. Authors just ignored in the post how they got that address. For that, you most likely need the information leak from second vulnerability, even if you can brute force the actual vulnerability.