4 ms·
I think behavioral analysis could be promising. There's a lot of weird stuff this code does on startup that any reasonable Debian package on the average install
by tux3 3y ago
I think behavioral analysis could be promising. There's a lot of weird stuff this code does on startup that any reasonable Debian package on the average install should not be doing in a million years.
Games and proprietary software will sometimes ship with DRM protection layers that do insane things in the name of obfuscation, making it hard to distinguish from malware.
But (with only a couple exceptions) there's no reason for a binary or library in a Debian package to ever try to write the PLT outside of the normal mechanism, to try to overwrite symbols in other modules, to add LD audit hooks on startup, to try to resolve things manually by walking ELF structures, to do anti-debug tricks, or just to have any kind of obfuscation or packing that free software packaged for a distro is not supposed to have.
Some of these may be (much) more difficult to detect than others, some might not be realistic. But there are several plausible different ways a scanner could have detected something weird going on in memory during ssh startup.
No one wants a Linux antivirus. But I think everyone would benefit from throwing all the behavioral analysis we can come up with at new Debian package uploads. We're very lucky someone noticed this one, we may not have the same luck next time.
- raggi 3y agoExcept had we been doing that they would have put guards in place to detect it - as they already had guards to avoid the code path when a debugger is attached, to avoid building the payload in when it's not one of the target systems, and so on. Their evasion was fairly extensive, so we'd need many novel dynamic systems to stand a chance, and we'd have to guard those systems extremely tightly - the author got patches into oss-fuzz as well to "squash false positives". All in all, adding more arms to the arms race does raise the bar, but the bar they surpassed already demonstrated tenacity, long term thinking, and significant defense and detection evasion efforts.
- tux3 3y agoI broadly agree, but I think we can draw a parallel with the arms race of new exploit techniques versus exploit protection. People still manage to write exploits today, but now you must find an ASLR leak, you must chain enough primitives to work around multiple layers of protection, it's generally a huge pain to write exploits compared to the 90s. Today the dynamic detection that we have for Linux packages seems thin to non-existent, like the arms race has not even started yet. I think there is a bit of low-hanging fruit to make attacker lives harder (and some much higher-hanging fruit that would be a real headache). Luckily there is an asymmetry in favor of the defenders (for once). If we create a scanner, we do not _have_ to publish every type of scan it knows how to do. Much like companies fighting spammers and fraud don't detail exactly how they catch bad actors. (Or, for another example, I know the Tor project has a similar asymmetry to detect bad relays. They collaborate on their relay scanner internally, but no one externally knows all the details.)
- raggi 3y agoYeah, perhaps something akin to an OSS variant of virustotal's multi-vendor analysis. I'm still not sure it would catch this, but as you say, raising the bar isn't something we tend to regret.
- saagarjha 3y agoThis is an arms race that is largely won by attackers, actually. Sophisticated attacks are caught by them sometimes but usually the author has far more knowledge or cleverer tricks than the person implementing the checks, who is limited by their imagination of what they think an attacker might do.
- wepple 3y agoI’m not sure that attackers “win” this arms race; the cost has gone through the roof and their chance of detection constantly increases. Indeed, defenders are often outgunned, but at a minimum we’ve pushed the level of effort way into nation-state territory, which is a good start.
- saagarjha 3y agoIndeed. But a lot of the effort has come from measures in areas that are much more stacked towards defenders (as it should).
- snnn 3y ago> to try to overwrite symbols in other modules, to add LD audit hooks on startup, to try to resolve things manually by walking ELF structures I want to name one thing: when Windows failed to load a DLL because a dependency was missing, it doesn't tell you what was missed. To get the information, you have to interact with the DLL loader with low level Windows APIs. In some circumstances Linux apps may also have the need. Like for printing a user friendly error message or recovery from a non-fatal error. For example, the patchelf tool that is used for building portable python packages. > No one wants a Linux antivirus It is not true. Actually these software are very popular in enterprise settings.
- ffsm8 3y ago> No one wants a Linux antivirus ClamAV has been around for a very long time at this point. It's just not installed on servers, usually
- kemotep 3y agoTo say nothing of enterprise EDR/XDR solutions that have linux versions. These things aren’t bulletproof but can be 1 layer in your multilayer security posture.
- EasyMark 3y agodon't most people who use that just use it for scanning incoming email attachments usually?
- snnn 3y agoClamAV also has a lot of findings when scanning some open source project's source code. For example, LLVM project's test data. Because some of the test data are meant to check if a known security bug is fixed, from a antivirus software perspective these data files can be seen as exploits. ClamAV is commonly used. Or, I would suggest adding it to every CI build pipeline. Most time it wouldn't have any finding, but it is better than nothing. I would like to offer free help if an open source project has the need to harden their build pipelines and their release process.
- everybackdoor 3y ago[dead]
- snnn 3y agoDoes not have to be installed. See this: https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-agentless-data-collection#how-agentless-scanning-works https://learn.microsoft.com/en-us/azure/defender-for-cloud/c... A cloud provider can take snapshots of running VMs then run antivirus scan offline to minimize the impact to the customers. Similarly, many applications are containerized and the containers are stateless, we can scan the docker images instead. This approach has been quite mature.
- robocat 3y ago> we may not have the same luck next time If the prior is 1 was out there (this one), the chances that there is 1+ still undetected seems fairly high to me. To behaviourally detect this requires many independent actors to be looking in independent ways(e.g. security researchers, internal teams). Edit: I mean with private code & tests (not open source, nor purchasable antivirus). It's not easy to donate to Google Zero. Some of the best funded and most skilled teams seem to be antivirus vendors (and high value person protection). I hate the antivirus industry yet I've been helped by it (the anti-tragedy of the commons). Commonly public detection code (e.g. open source) is likely to be defeated by attackers with a lot of resources. Hard to protect ourselves against countries where the individuals are safe from prosecution. Even nefarious means like assasination likely only work against individuals and not teams.
- bandrami 3y ago> If the prior is 1 That would surprise me greatly
- lazyasciiart 3y agoI think you’re saying “I would be surprised if there is only 1 exploit like this that already exists” which is what the previous comment was also saying. “If the prior is one” is often used to mean “we know for sure that there is one”.
- cryptonector 3y ago> But I think everyone would benefit from throwing all the behavioral analysis we can come up with at new Debian package uploads. Why "new uploads" and not also "all existing"?
- cipherzero 3y agoSorry, I'm unfamiliar with PLT what does stand for?
- intelVISA 3y agoprocedure linkage table