5 ms·

The challenge of reverse debuggers is knowing when it should dispose of the recording; otherwise, if the debugger keeps recording the full sequence of states an

The challenge of reverse debuggers is knowing when it should dispose of the recording; otherwise, if the debugger keeps recording the full sequence of states and actions, it would cause a memory leak and/or unbounded growth in disk usage. Such debugger would not be able to sustain a DoS attack if debugging in production (it would spam the debugger with lots of different states generated by the attacker); in fact, it would likely make it easier for an attacker to DoS a service as it would consume computational resources.

mark_undoio 4y ago
> if the debugger keeps recording the full sequence of states and actions, It's worth noting that the main time travel debugging technologies don't keep the state of every operation performed, only the non-deterministic ones (i.e. where new information flows into the recorded program). A compute-intensive simulation can run a few days and generate little-to-no state that needs recording. Your point stands, though, that a malicious attacker could do many non-deterministic operations (e.g. read data in from a socket). This can be solved - relatively easily - with a circular logging approach is workable to address this. i.e. discard chunks of older history to free up space as you go. (Whether individual time travel debuggers support that is, as far as I'm aware, more a case of balancing demand for the feature against engineering effort.) > Such debugger would not be able to sustain a DoS attack if debugging in production (it would spam the debugger with lots of different states generated by the attacker); in fact, it would likely make it easier for an attacker to DoS a service as it would consume computational resources. In-production use could potentially be very useful if that's where some weird flaky issue occurs, so this is worth worrying about. It's definitely true that you've got to have the resources / settings to not overwhelm your machine. The other thing is that adding a complex layer of additional software risks adding additional exploits into the mix. If your production issue is at a customer site or in a semi-trusted context (corporate network service) - which for some software is the norm - then I think that makes the threat model a bit less scary. Otherwise, I guess it's a case of sandboxing the software within other measures and maybe spawning a separate instance that's recorded so you've still got "normal" instances running in parallel?
invalidname 4y ago
Never use these things in production. They slow your servers very noticeably. It's OK for development. QA and even for unit test runs (which is an amazing use case for flaky tests). But production is a completely different ballgame.

mark_undoio 4y ago

> if the debugger keeps recording the full sequence of states and actions, It's worth noting that the main time travel debugging technologies don't keep the state of every operation performed, only the non-deterministic ones (i.e. where new information flows into the recorded program). A compute-intensive simulation can run a few days and generate little-to-no state that needs recording. Your point stands, though, that a malicious attacker could do many non-deterministic operations (e.g. read data in from a socket). This can be solved - relatively easily - with a circular logging approach is workable to address this. i.e. discard chunks of older history to free up space as you go. (Whether individual time travel debuggers support that is, as far as I'm aware, more a case of balancing demand for the feature against engineering effort.) > Such debugger would not be able to sustain a DoS attack if debugging in production (it would spam the debugger with lots of different states generated by the attacker); in fact, it would likely make it easier for an attacker to DoS a service as it would consume computational resources. In-production use could potentially be very useful if that's where some weird flaky issue occurs, so this is worth worrying about. It's definitely true that you've got to have the resources / settings to not overwhelm your machine. The other thing is that adding a complex layer of additional software risks adding additional exploits into the mix. If your production issue is at a customer site or in a semi-trusted context (corporate network service) - which for some software is the norm - then I think that makes the threat model a bit less scary. Otherwise, I guess it's a case of sandboxing the software within other measures and maybe spawning a separate instance that's recorded so you've still got "normal" instances running in parallel?

invalidname 4y ago

Never use these things in production. They slow your servers very noticeably. It's OK for development. QA and even for unit test runs (which is an amazing use case for flaky tests). But production is a completely different ballgame.