Maybe more things should be randomized like the stack canaries. Is that a new idea? On Fri, Oct 13, 2017 at 11:34 PM Theo de Raadt <[email protected]> wrote:
> > I read "hacking blind." Can you restart a daemon with another forked > > process that's only job is to monitor a pipe or a waitpid()-like > operation > > and if the parent dies, it exec's to restart it, or even execs "rcctl > > restart ntpd" > > > > If the mitigations are successful at limiting execution to let's say, > > overwriting a canary that gets completely rerandomized with a fork-exec, > > instead of just a fork, it would stop a meaningful search for the correct > > canary to just blind luck instead of byte by byte discovery. > > your position is very roughly: that paper lays out the absolute limit > of what someone could learn from broken software, so as long as we run > a new copy of the broken software we'll be safe........ > > obviously, no downside. > > you say "completely rerandomized" -- uhm no, only a tiny fraction of > the program execution environment and runtime are randomized, in > particular same registers used everywhere, same instruction sequences, > same frame layouts, same register and stack leave-behinds, same > relative offsets inside each DSO.... > > nothing learned from re-running buggy software? sorry, that is BS. >
