Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

421–430 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#421
post #420

Allow me to name drop the single worst uninstaller I have ever seen: Doxillion Document Converter by NCH software. It has been 4+ years, and I am still manually cleaning up stuff it left behind on my machine. Do not use anything by this company, unless you intend to reimage after.

[deleted]

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#422

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.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#423

Why is the stack marked as executable? This is no longer 1995.

you could with anti-exploit techniques (or within windows itself) hook VirtualProtect and such functions to check if its not making the stack executable. Also you could check it on process startup. However, it won't solve much, because then you simply slap it on the executably mapped heap region and do it from there?

There are cases for allowing memory protections to be changed, and because of that, it's possible and people use it. (code-generation / JIT etc.)

the stack being executable used to be a big problem, for example in 1995 with things like stack overflows running wild, but I think those have been largely mitigated by having things like stack canaries/checks stop stack overflows from being done (stack smashing detected!). those canaries were introduced around 1999 or so, and yes there are ways around it (rops/jops etc.), but not through the simple overflows from 1995.

I am all for not allowing it, but admittedly, that's likely some impractical utopian stance on the matter regarding the current use of operating-systems.

Perhaps in 2995 :)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#424
I had an old hacky community program basically ruin my Windows install so I agree, it was a BLP viewer it automatically added previews on windows explorer, but if yo u removed a file while previewing a blp it'd crash your explorer and all your open tabs would close, really annoying.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#425

Earlier quoted context omitted.

For the curious: Here's a completely unfinished guide to how you might start developing such an application: https://marksweb.site/hta/ From HTAs, you have access to the file system, the network, the registry, the shell - everything. It might be a bit different than normal web dev, but it's not too bad either.

Wow, that's so cool! I played around with making HTAs as a kid and never thought those could be that powerful. (I quickly moved on to topics more exciting to a teenage hacker, like making WinForms apps with some PHP RAD IDE.) Wondering what would it take to port mshta (with all the ActiveX goodies) to other platforms. Maybe it's a little bit late for that, but sounds like it might be a fun project to me.

You're brave, putting "ActiveX" and "fun" in the same sentence.

Wine Gecko supports ActiveX, supposedly, so if someone implements all the common ActiveX components, that could be a cross-platform method of running HTAs outside of Windows.

That said, I'm afraid the Electron API is the closest thing we have to a cross platform HTML application these days. On Manjaro, several packages are already implemented by installing Electron next to the application specific code, so that would be the closest thing to a modern HTA alternative that I know of.

PWAs work fine if you don't need integration with the system itself other than file prompts, for chat apps for example. They're not really alternatives to HTAs to be honest.

It should be noted that HTAs are a common way to infect computers (because they're executables that aren't usually recognised as such) and they're disabled in many security conscious environments.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#426
post #260

Earlier quoted context omitted.

The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applicat…

I agree with you, now for completeness I should mention that Linux package formats usually allow packagers to provide arbitrary pre- and post- install shell scripts ran as root. (which means that if you don't trust a provider, not only it's not safe to run the program, but it's also unsafe to install it)

Right. You should generally never install a proprietary software package provided by the vendor in RPM, DEB, or similar. What keeps the use of those hooks safe is purely social convention and review internal to the Linux distribution, and vendors routinely use those hooks to do unacceptable things.

If you must install proprietary software on your Linux system, either package it yourself or use something like Flatpak or Snap (or even AppImage).

Hopefully in the future vendors will increasingly move to providing well-sandboxed Flatpak packages by default.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#427

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…

Being pedantic, you can delete open files on Windows if you open them with FILE_SHARE_DELETE.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#428
post #409

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…

>How is the proposed solution better than the original thing? I'm only assuming here, but maybe because it won't crash explorer and it's just a few lines of self-documenting code?

Haha, well fair enough the crash is bad indeed, good point! This isn't intended behavior though and presumably, it doesn't crash on in cases of this technique being implemented in uninstallers. (a bit of a guess i admit!)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#429

Earlier quoted context omitted.

It more or less doesn't in MacOS, and has NEVER really been a thing. While there ARE some tools that require a more invasive "installation" process (e.g., VMWare Fusion), the overwhelming majority of Mac software is installed by just dragging the application bundle into /Applications. (App bundles are just special directories, more or less, so you're moving more than just the file, but it presents as a single thing.)…

It's a bit weird to act as if macOS didn't have installers and uninstallers. For one thing, there's the App store. And then, probably most developers use something like homebrew. What you describe works for a specific kind of app, the ones that can be easily sandboxed and don't have shared dependencies.

Most of my apps in my daily driver Mac were installed this way.

Notable exceptions: Microsoft office, Google Drive.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#430

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.

It's never been entirely clear to me why windows provides such a rich interface for one process to inject and start executing code in the address space of another but IMHO I want to know when this is happening even when it's done by a "legitimate" uninstaller.

Post reply on HN