What if we had mutex revocation lists?

This is classic cat and mouse. Once most AV vendors and OSs support this, they will find a different way. In other words, increased complexity for a temporary relief.<p>It&#x27;s really is about time that OS vendors to start looking at this problem differently. There is a part of the system that is for the system only, and a part that is for the user. Keep the two seperate, 100%. Each and every program should be in their own little sandbox, so any compromises are confined to that sole program.<p>Sandboxing this way will not make the problem go away, but it will significantly reduce the attack surface that needs to be hardened to prevent a random exploit to be used to jump to a systemwide exploit.

They&#x27;ll just do what the very first piece of malware did - add a small random chance of re-infecting the machine, even if the malware seems to be present already.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Morris_worm#The_mistake" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Morris_worm#The_mistake</a>

I think there are many many ways for a program to detect if it was loaded &#x2F; infected that would not require the use of a system wide mutex -- many would not result in increasing the chance of discovery. So I think adding mutex revocation list would result in false sense of security.<p>While it may combat existing malware it would only be a temporary inconvenience.<p>Not to be too harsh, I feel like solutions like this tend to forget that these are computer programs we are talking about. The entire concept of them is to be able to do things within the constraint of the hardware. The notion that mutexes are a construct coded by a programmer one would expect to be able to make their own mutex without the help of the underlying framework&#x2F;library you are using today.

The malware would use some other mechanism, or would use some semi common mutex name. Something out of Photoshop or AutoCAD or whatever, to really annoy enterprise licensees of AV tools that went for that mechanism. (I assume most of those who pay ransomware are individuals, as enterprise would have automated backups and machine imaging for recovery.)

If this technique became common, malware would just switch to another approach to determine if it had already infected a machine. It&#x27;s a cat and mouse game where the cost of defense is much higher than the cost of attack.

Lots of ways around this, for example:<p>* Use an expensive KDF to derive the mutex name from some hardware attribute like the mac address or processor serial number (e.g. it takes 5s to compute, and must be done on each machine) - as soon as there are thousands of such malware codes using this approach, the AV would become commercially unreasonable. The existing infection could even include the time in the KDF input and rotate mutexes every hour.<p>* If an infection is detected by the mutex, the new instance tries to use IPC to connect to the existing instance and follow a protocol to verify its validity.<p>* Some other resource is used to ensure mutual exclusion of infections. Binding to a port on localhost, locking a file, writing a temporary file, creating a named pipe, creating a process with an obscure name in the process list, creating shared memory, etc...<p>* A statistically detectable behaviour is used to signal presence. For example, any Windows process can get the free system memory - an existing infection could regularly monitor free memory and then allocate or free memory to make sure the free memory stays as a multiple of some number. A new infection could then monitor free memory, and if it stabilises to the magical multiple, allocate memory, check if the free memory changes to the multiple, and repeat until it has confidence of an infection. A similar approach could be to look for an encoded signal in the pattern of CPU usage over time (it might only work when the system is mostly idle, but that might be good enough). Potentially this could be done using sleeps and accessing the system clock, so would be very hard to block.<p>All in all, I agree with some of the other comments that this a cat and mouse game, and it is stacked against the cat (AV vendor).

A bit late here so perhaps commenting into the void, but here&#x27;s my £0.02 anyway ... :)<p>Creating a system mutex ought be a capability e.g. in capsicum <a href="http:&#x2F;&#x2F;www.cl.cam.ac.uk&#x2F;research&#x2F;security&#x2F;capsicum&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.cl.cam.ac.uk&#x2F;research&#x2F;security&#x2F;capsicum&#x2F;</a><p>Applications ought have to whitelist the named mutexes they can create.

I always use mutexes based on machine unique characteristics. Obviously one can still reverse engineer the algorithm and ship AV updates to keep those mutexes. But that&#x27;s more work than shipping in.txt and out.txt full of strings to your anti virus clients. In the end I think that this ultimately does not mitigate the discrepancy between attacker and defender costs.

Pointless idea. You can coordinate in mamy ways, mutex is just one way. Also, you can hash MAC with a stable id to get different mutex on every machine. You can also change mutexes, new versions may check multiple names. Sorry.