-
Notifications
You must be signed in to change notification settings - Fork 586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rr is unsafe to run on potentially malicious code #3705
Comments
Actually the usual case for Firefox and Chrome devs using rr is that they're debugging test cases which are known to be non-hostile, so that's fine. But recording a browser session involving potentially hostile Web content seems fine too. rr does not flat-out disable the browser sandbox, it just pokes a very specific small hole in it. The odds that a real Web site is carrying a malicious payload that specifically targets that hole poked by rr must be infinitesimal. Why would anyone do that? I'm sure you are much more likely to encounter Web content that uses a regular bug-exploiting sandbox escape. If you're debugging a browser using rr and you're worried about an attacker trying to specifically target you, you should run the browser and rr in a VM guest using something KVM-based. An AWS EC2 VM works fine. But against such a sophisticated attacker, you should probably do that even if you're not using rr.
Sure it does: https://github.com/mirage/xen/blob/master/xen/arch/x86/cpu/vpmu.c |
I was not aware of that. My use-case was tracking down with crashes found by end-users, such as QubesOS/qubes-issues#8960 (Firefox crashes for no apparent reason).
Attackers benefit massively from automation. An attacker might be using a payload that tries a whole bunch of different exploits. Spyware like Pegasus does exactly that.
Indeed it does, though only in the largest (and thus most expensive) sizes (because AWS EC2 blocks performance counter use on smaller VMs for security reasons).
That is why I use and develop Qubes OS, which does the same thing but with Xen VMs.
The functionality exists, but it is not supported security-wise, which means that I cannot ask end-users to use it. See XSA-163: virtual PMU is unsupported. Is this just me wanting to use rr for something it was never meant for? |
Sure, but someone would have to develop an exploit specifically targeting rr first, i.e. to specifically target browser developers who use rr on public Web content, which is a VERY small set of people. I probably know most of their names! And the chance that you'll ever get those users to load your payload while they're recording the browser with rr is still incredibly small.
rr works in c5d.9xlarge instances which cost < $2/hour. That's essentially nothing compared to the value of a developer's time. I understand that that doesn't work for Qubes-specific issues that you want to debug, but it would work for just about everyone else.
So you want end-users to send you rr recordings of the Web browser for debugging? There are bigger problems with that. In particular it's difficult to ensure that those recordings don't contain their private information.
I guess so? We do specifically warn against using rr to debug malicious code: https://github.com/rr-debugger/rr/wiki/Usage#malicious-code It might be possible to harden rr for safe recording and replaying of malicious code, but it would be a lot of work to implement and more importantly to test, and it just doesn't seem worth it when most users can just run it in a relatively cheap AWS VM instead. |
I was thinking of a separate (fresh) profile with no information saved, but you are correct. I don’t think there is a good solution here, beyond what ABRT does. |
From @DemiMarie:
The text was updated successfully, but these errors were encountered: