That’s a problem with a lot of code diversity approaches. If I understand what’s happening here, it isn’t such a problem because it does a random link and then you have the linked ELF file on disk, so as long as you get that along with the core dump, you’re fine. OpenBSD doesn’t have any telemetry mechanisms for shipping core dumps to people doing the debugging, so getting the core dump is a manual process and getting the core dump and the binary is a slightly more difficult manual process.
The security is somewhat weaker here then other approaches because if you have an information disclosure vulnerability that lets you dump a bit of the code and then crash, sshd will restart with the same layout and so you can then do the next probe until you have enough for a code-reuse attack. More robust approaches rerun the randomisation at every launch. Combined with the recent XOM support in OpenBSD, probes are quite hard anyway.
It might also be sufficient to watch for sshd terminating abnormally and rerandomise before restarting it.
sshd uses fork+exec and will have multiple processes…you need to be clearer here when you say “sshd will restart.” A child process that’s the result of fork+exec will have a different address space layout even if the .text segment is the same.
A child process that’s the result of fork+exec will have a different address space layout even if the .text segment is the same.
But not as a result of this, it will have the same mitigations as a process that does not do this. If you are able to leak some of the layout of the text by following some pointer that leaks the location of the place where the code is mapped then you can keep probing until some IDS notices.
This seems like it would make it impossible to debug from core dumps. That is, if you get core dumps.
That’s a problem with a lot of code diversity approaches. If I understand what’s happening here, it isn’t such a problem because it does a random link and then you have the linked ELF file on disk, so as long as you get that along with the core dump, you’re fine. OpenBSD doesn’t have any telemetry mechanisms for shipping core dumps to people doing the debugging, so getting the core dump is a manual process and getting the core dump and the binary is a slightly more difficult manual process.
The security is somewhat weaker here then other approaches because if you have an information disclosure vulnerability that lets you dump a bit of the code and then crash,
sshdwill restart with the same layout and so you can then do the next probe until you have enough for a code-reuse attack. More robust approaches rerun the randomisation at every launch. Combined with the recent XOM support in OpenBSD, probes are quite hard anyway. It might also be sufficient to watch for sshd terminating abnormally and rerandomise before restarting it.sshduses fork+exec and will have multiple processes…you need to be clearer here when you say “sshdwill restart.” A child process that’s the result of fork+exec will have a different address space layout even if the.textsegment is the same.But not as a result of this, it will have the same mitigations as a process that does not do this. If you are able to leak some of the layout of the text by following some pointer that leaks the location of the place where the code is mapped then you can keep probing until some IDS notices.