Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

Post reply on HN
Print view View original

431–440 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#431

Post by robinsonb5 »

drbig wrote: post #418

I still long for the approach many software used on the AmigaOS - the app is a folder, the folder has the main exec and any assets it needs (libraries, images, etc.) and documentation and... That's it. Install? Copy the directory to where you like. Uninstall? Delete the directory. And if you wish you could keep any files used/generated with such an app in the same folder, making it 100% self-contained. I remember bei…

I still love most aspects of the Amiga user experience, but a lot of Amiga applications would need libraries installed to Libs: and deleting the application's "drawer" would leave those libraries behind. (Having said that, by default libs: is assigned to sys:libs but you could assign extra targets, so that libraries would be sought from application-specific directories.)

Also, it suffers from the same problem as Windows here, in that you can't delete a file or directory which is currently open. The executable itself wouldn't be open after launch is complete (with the possible exception of overlay executables, but they were pretty rare) but the directory would be locked for as long as it was the program's current directory. If a subdirectory with app-specific libraries was assigned to Libs: that would also prevent deletion.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#432

Post by sim7c00 »

thombat wrote: post #422
sim7c00 wrote: post #399

The author says the binary looks like malware because it self-deletes, sleeps and touches this uninstaller thing. But the script he proposes, which would be triggered by this same thing, does the same. I am ignoring the injection thing since he guesses at it (likely correct) and also because, lots of things inject into processes without being malware. (monitoring stuff like AV etc.) Additionally, binaries which termi…

It's more about how it does it: injecting executable code directly into the stack so that some other code unwittingly transfers control to it. Stack-smashing is a lot more malware-ISH than a few lines of shell script.

They inject something into Explorer. I would assume that to be some DLL that is injected?

---- Neither code injection nor detouring is officially supported. I can’t tell who did the detouring. Maybe somebody added a detour to the uninstaller, unaware that the uninstaller is going to inject a call to the detour into Explorer. Or maybe the detour was injected by anti-malware software. Or maybe the detour was injected by Windows’ own application compatibility layer. Whatever the reason, the result was a crash in Explorer. ----

I'd think the anti-malware guess here would be correct, and that (DLL) injection was stopped, and thus some crash happened. Thanks for your reply.

The DLL would execute something from its stack so it can be somewhat dynamic (perhaps some path or something is generated before the injection or so - really little to go on here...) and not need to make a heap allocation within Explorer.exe. (this is perhaps a bit too much to assume idk.)

Thanks for your insights!

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#433

Post by ChrisSD »

pie_flavor wrote: post #312
rk06 wrote: post #237

Earlier quoted context omitted.

If the sysadmin chooses to, otherwise PowerShell can be run arbitrarily

The key is that unsigned scripts are opt-in, not opt-out. Chen is not going to suggest a solution that requires all users of the software to configure their computer to be less secure.

It's not really a security measure in that sense. It's a "safety feature" that prevents accidentally running such a script. Anything can trivially disable the protection using a bat script (or anything else) to bootstrap.

E.g. `powershell.exe -ExecutionPolicy Unrestricted`

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#435

Post by mavhc »

EvanAnderson wrote: post #292
blackpill0w wrote: post #149

Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?

Windows has had an installer as an OS component since the late 90s (called Windows Installer). As a sysadmin I'd prefer apps use it. Many application developers do not. It's maddening. (Doubly so when Microsoft themselves don't use it-- newer versions of Office, Teams, etc. Microsoft suffers from too much NIH.) I get unattended installs and uninstalls "for free" when well-behaved applications use Windows Installer. P…

As soon as Office 2007 didn't use MSI the format was doomed.

I assume the Here in NIH refers to an individual team, not MS as a whole.

Teams is entirely NIH https://github.com/Squirrel/Squirrel.Windows for updates to the Electron app.

I would use winget, but MS made it weirdly hard to run as a script on multiple computers, it installs per user, because... who knows.

So still using chocolatey

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#436

Post by sim7c00 »

ghostpepper wrote: post #430
sim7c00 wrote: post #399

The author says the binary looks like malware because it self-deletes, sleeps and touches this uninstaller thing. But the script he proposes, which would be triggered by this same thing, does the same. I am ignoring the injection thing since he guesses at it (likely correct) and also because, lots of things inject into processes without being malware. (monitoring stuff like AV etc.) Additionally, binaries which termi…

Once you move past comparing hashes against known malware (by definition useless against novel malware), and the slightly more complex matching of specific binary strings, detecting malware with "shitty heuristics" is basically all we've got. Companies that buy AV/EDR products expect them to detect unwanted behaviour while allowing any sort of weird, hacky, abuses of the system that they rely upon for their business.…

The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice.

AV/EDR products do try to prevent a lot of stuff. They can 'generically' block things like injection etc. by 'hooking all the things' and injecting into everything (yes, yuck :D and still kind of heuristic based i admit!) to make certain sections read only or remove executable mappings etc. (got/plt/stack/...)

Linux or more specifically ELF files also have an easy vector to allow injection by having a dynamic table entry for debugging purposes which can be trivially overwritten for example. "ibc.so" :(). I'm not sure anyone uses that entry validly... especially since there's better/less awkward debugging interfaces than injecting a debugger DLL into something :') at least in x86/64 Linux land. (ELFShell sure was fun tho!)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#437

Post by sim7c00 »

kazinator wrote: post #413
sim7c00 wrote: post #399

The author says the binary looks like malware because it self-deletes, sleeps and touches this uninstaller thing. But the script he proposes, which would be triggered by this same thing, does the same. I am ignoring the injection thing since he guesses at it (likely correct) and also because, lots of things inject into processes without being malware. (monitoring stuff like AV etc.) Additionally, binaries which termi…

The .js script isn't injecting code into another program in order to deletee itself; it is deleeting itself directly. It can do that because, I'm guessing, the file isn't open; the run-time isn't executing instructions from that file. The file was read, the content compiled into memory, and closed. The script is deleting its source code, not itself. What actually deletes the script itself is the garbage collector in…

The script doesn't inject. But a lot of malware downloads a script and runs it, so you'd hit another rule.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#438

Post by pxc »

simiones wrote: post #307
mjan22640 wrote: post #262

Earlier quoted context omitted.

A VSCode extension would be installed and managed by the OS package manager. User created content would be not.

Really? Do you install Firefox extensions from apt-get?

It's not unusual to do this in the Nix world.

There are a ton of VSCode extensions in Nixpkgs: https://search.nixos.org/packages?channel=23.05&from=0&size=...

You can use them in combination with the vscode-with-extensions function to create a VSCode package that bundles in whatever extensions you declare: https://nixos.wiki/wiki/Visual_Studio_Code

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#439

Post by sim7c00 »

oefrha wrote: post #411
sim7c00 wrote: post #399

The author says the binary looks like malware because it self-deletes, sleeps and touches this uninstaller thing. But the script he proposes, which would be triggered by this same thing, does the same. I am ignoring the injection thing since he guesses at it (likely correct) and also because, lots of things inject into processes without being malware. (monitoring stuff like AV etc.) Additionally, binaries which termi…

Maybe it’s less likely to be flagged or interfered with by antivirus? Antivirus uses all kinds of shitty heuristics, seeing that my Go executables built with -ldflags="-H windowsgui" are flagged as malware by Windows Defender and co. all the time. It’s maddening.

that's fair enough. perhaps they can more easily in AV land make some kind of signature that whitelists this self-deletion javascript method because the script is more readable. though i'd expect a good AV to be at least worried if some executable on my system runs a script file via a scripthost.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#440

Post by danbruc »

oefrha wrote: post #396
danbruc wrote: post #336

Earlier quoted context omitted.

So what? Building an operating system necessarily requires making countless design decisions, trading some things for other things. Over the decades the best choices may even change as technology advances but you might be unable to change course because you have a huge number of installations and would cause a lot of issues.

> So what? So your entire comment was completely wrong. It’s not shameful to admit you’re wrong, it is shameful when someone else points out your mistake and you pivot to a “so what”.

No, you are confusing things - reasons are not necessities.
Post reply on HN