zlacker

[parent] [thread] 23 comments
1. Yoric+(OP)[view] [source] 2023-04-05 21:04:49
In my experience (as a former Firefox dev), antivirus / antimalware software are really poorly behaved. They tend to:

- require admin rights (which means that if they have vulnerabilities, it can take control of the entire machine, even if Firefox itself is sanboxed);

- monkey-patch the Firefox executable in memory, which works (when it does) as long as the version of the software tracks closely the version of Firefox, which may or may not be the case;

- ... and also decreases the memory-safety of Firefox, which makes it easier to pwn;

- ... and also makes the crash reports unreliable;

- install encryption certificates that are actually less trustworthy than Mozilla's, hence decreasing the security of https;

- block Firefox and add-on security updates, also decreasing security;

- install privileged add-ons, many of which are easy to exploit from any webpage;

- ...

Part of the work on Crash Scene Investigations was attempting to determine whether the crash was in Firefox or in code or in some bogus foreign code. Depressingly often, it was the latter.

In your case, it's entirely possible that malwarebytes was simply untested on Firefox.

replies(5): >>genoci+qb >>jbritt+lj >>bboygr+qX >>mschus+Qj1 >>maccar+Fs1
2. genoci+qb[view] [source] 2023-04-05 22:08:33
>>Yoric+(OP)
> - monkey-patch the Firefox executable in memory, which works (when it does) as long as the version of the software tracks closely the version of Firefox, which may or may not be the case;

This one was a frustratingly common cause of crashes when I worked in gamedev. So many crashes would end up being some overlay or antivirus monkeying about with memory.

3. jbritt+lj[view] [source] 2023-04-05 22:51:35
>>Yoric+(OP)
I had always assumed that one application could not touch the memory of another application. Does running as Admin allow breaking this boundary?
replies(7): >>codedo+Yk >>rootw0+Jl >>genoci+qx >>genewi+nG >>jchw+IK >>swagmo+6L >>Iwan-Z+CT
◧◩
4. codedo+Yk[view] [source] [discussion] 2023-04-05 23:02:57
>>jbritt+lj
This is wrong, on Windows there are system calls to access memory of other process and on Linux you can do it using debugging. Also on Windows there is a tradition to inject libraries into other processes, create threads in processes etc.
replies(1): >>accoun+9m1
◧◩
5. rootw0+Jl[view] [source] [discussion] 2023-04-05 23:06:46
>>jbritt+lj
Yes. However, I think parent process can gain access to child process memory without admin rights.
replies(1): >>insani+BP
◧◩
6. genoci+qx[view] [source] [discussion] 2023-04-06 00:22:34
>>jbritt+lj
Yes, in general on Windows processes with higher privilege levels can get access to read/write another processes memory, or even inject code into them. And even Admin-level processes can still be broken into by something running as a service with even more elevated privileges like NT AUTHORITY\SYSTEM.

This has long been a leaky part of Windows security. If your malware can get its code running inside a highly privileged service or process, it can do more or less whatever it wants to the rest of the system. But even when not used for nefarious purposes, it is still an extremely dangerous capability in that it can be very easy to create problems .

replies(1): >>Hikiko+pm1
◧◩
7. genewi+nG[view] [source] [discussion] 2023-04-06 01:38:03
>>jbritt+lj
cheatengine, wemod, and so on would not be able to work if this were the case. Thankfully those all work, at least up to windows 10!
replies(2): >>genoci+gT >>jquery+uW
◧◩
8. jchw+IK[view] [source] [discussion] 2023-04-06 02:14:10
>>jbritt+lj
By default, any application's memory can be read and written to by other processes running as the same user, as far as I know. The way to deal with this is to set process security descriptors, but admin can still bypass this. There are protected processes, and protected processes light, but those are not used by most software (mainly anti-malware afaik.)

https://learn.microsoft.com/en-us/windows/win32/procthread/p...

replies(1): >>userbi+hR
◧◩
9. swagmo+6L[view] [source] [discussion] 2023-04-06 02:16:38
>>jbritt+lj
This is an EXTREMELY common pattern in the world of Windows... Especially with antivirus
◧◩◪
10. insani+BP[view] [source] [discussion] 2023-04-06 02:57:51
>>rootw0+Jl
All that's generally required is being the same user at the same or higher integrity.
◧◩◪
11. userbi+hR[view] [source] [discussion] 2023-04-06 03:10:36
>>jchw+IK
There are protected processes, and protected processes light, but those are not used by most software (mainly anti-malware afaik.)

...and DRM.

replies(1): >>jchw+6T
◧◩◪◨
12. jchw+6T[view] [source] [discussion] 2023-04-06 03:26:14
>>userbi+hR
Although that was definitely the intent, I actually don't know about specific things that use it. I'd love to hear what actually uses it. (I don't think Widevine l3 does, for example.)
replies(1): >>monoca+D01
◧◩◪
13. genoci+gT[view] [source] [discussion] 2023-04-06 03:27:12
>>genewi+nG
Or userland debuggers.
◧◩
14. Iwan-Z+CT[view] [source] [discussion] 2023-04-06 03:30:58
>>jbritt+lj
How you debug then?
◧◩◪
15. jquery+uW[view] [source] [discussion] 2023-04-06 04:04:28
>>genewi+nG
They work just fine in windows 11 so far.
16. bboygr+qX[view] [source] 2023-04-06 04:14:39
>>Yoric+(OP)
This almost reads like Defender makes machines less secure on purpose.

Makes me wonder: Does windows Defender just double as another deliberate NSA backdoor?

replies(2): >>foepys+pY >>tsujam+Dg1
◧◩
17. foepys+pY[view] [source] [discussion] 2023-04-06 04:25:08
>>bboygr+qX
Why would Microsoft need to put a NSA backdoor specifically into Defender when it could put it anywhere else into Windows with their monthly patch? It doesn't make sense to single out Defender.

The same is valid for Apple, Google, and every other US company.

◧◩◪◨⬒
18. monoca+D01[view] [source] [discussion] 2023-04-06 04:49:24
>>jchw+6T
I seem to recollect that iTunes did, but maybe that was just on OSX.
◧◩
19. tsujam+Dg1[view] [source] [discussion] 2023-04-06 07:12:42
>>bboygr+qX
Pretty sure Defender is one of the few anti malware/edr that doesn’t need to do this, because it’s so tied to the platform. 3rd party antimalware and EDR are much more likely to inject hooks and dlls into other processes
20. mschus+Qj1[view] [source] 2023-04-06 07:37:57
>>Yoric+(OP)
> - install encryption certificates that are actually less trustworthy than Mozilla's, hence decreasing the security of https;

Given that in many industries insurances and, in some cases like banking, the law requires companies to monitor HTTPS traffic of browsers for compliance, it might be better if browsers had a dedicated filter / monitor API.

replies(1): >>Yoric+Tm1
◧◩◪
21. accoun+9m1[view] [source] [discussion] 2023-04-06 07:56:38
>>codedo+Yk
On Linux, ptrace permissions can be restricted [0] and some distributions do this by default.

Whether this provides any meaningful security is questionable unless you pair it with filesystem isolation to prevent malicious programs from modifying config files / bashrc / etc. Meanwhile it does make legit uses of ptrace more annoying.

[0] https://www.kernel.org/doc/Documentation/security/Yama.txt

◧◩◪
22. Hikiko+pm1[view] [source] [discussion] 2023-04-06 08:01:17
>>genoci+qx
Anything you run as your user can be accessed.
◧◩
23. Yoric+Tm1[view] [source] [discussion] 2023-04-06 08:07:52
>>mschus+Qj1
WebExtensions definitely have such an API. That's how AdBlock, uBlock, etc. work.
24. maccar+Fs1[view] [source] 2023-04-06 09:03:29
>>Yoric+(OP)
> Part of the work on Crash Scene Investigations was attempting to determine whether the crash was in Firefox or in code or in some bogus foreign code. Depressingly often, it was the latter.

A shockingly large number of crashes and performance issues in PC gaming are related to poorly behaved overlay programs and overclocking tools like RivaTuner, Overwolf, and the Discord Overlay. I'd well believe your points.

[go to top]