Hacker News Reader

Comment by rwmj | Hacker News Reader

Why doesn't he keep the encoded .exe as an adjacent registry key, and have the powershell script open that key, decode the content and run it?

Anyway once you've persuaded the user to import a .reg file as administrator, it's game over. There are so many registry entries with exploitable possibilities. (It's similar to persuading a Linux user to unpack a tarball over /etc)

While I'm here...

hivex is a Linux library for accessing and modifying the Windows registry (https://github.com/libguestfs/hivex), and virt-win-reg is a Linux tool for modifying the registry of a VM (https://libguestfs.org/virt-win-reg.1.html). After many hours discovering how the registry works to write those, I also wrote this about why the registry sucks: https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...

View on HN

I actually miss the .ini files of early DOS / Windows days, with the defacto convention of storing them in their related program directory.

They were easy to examine and edit with text tools, and you could do things like diffs. And when you delete the program directory, they go away as well.

I used Total Uninstall on a couple Windows 7 workstations for over a decade and really paid attention to curating my registry against bloat. Almost every software out there leaves waste behind in your registry after you uninstall it.

I reported some of the most egregious cases to developers/publishers over the years... a few even got fixed.

But the ecosystem is a mess. I'm not sure Microsoft ever realized the importance of hammering on best practices and providing the tooling to make them effortless to follow. Even their internal teams have done some ugly stuff over the years.

Same here, there was nothing wrong with them.

Microsoft has been pushing for xml configuration files alongside applications, but even their own teams don't listen, so here we are.

> Almost every software out there leaves waste behind in your registry after you uninstall it.

I think this is just a design flaw of the implementation itself.

Why couldn't every entry have a few more fields under the hood:

  programsDependingOnThisEntry: [PROGRAM_FOO, PROGRAM_BAR]

I know that this might bloat the overall size of it, but in my experience most data structures that aren't a graph of some sort but need to be used by multiple consumers will eventually become full of orphaned data.

In this example, references to actual installed programs would make sure that when you have orphaned data it can be removed automatically (or the choice given to you), much like apt might suggest that you have some packages that aren't used by any other piece of software anymore.

For informative purposes, maybe also add:

  entryFirstAdded: 2005.05.15 14:00
  entryLastChanged: 2006.11.04 17:35
  entryLastRead: 2008.10.13 13:00

The timestamps could optionally assist in figuring out when the values were changed/added/actually used, so you know how important something is. If an entry hasn't been accessed in 5 years of your daily usage or something, quite possibly it isn't awfully important.

Interestingly - as the article argues the registry is basically a crappy filesystem - the real (NTFS) filesystem already has all three of those date entries (created, modified, accessed).

I agree it would be nice of all data could be seamlessly associated with the programs that have touched it. I think Android/Apple kind of do this by giving each app its own storage sandbox / directory (to some extent).

>Anyway once you've persuaded the user to import a .reg file as administrator, it's game over.

relevant Raymond Chen https://devblogs.microsoft.com/oldnewthing/20150923-00/?p=91...

> (It's similar to persuading a Linux user to unpack a tarball over /etc)

Would this allow for arbitrary code execution? Curious as a Linux amateur

you could put a cron entry by dumping a file into /etc/cron.d/

run any command as any user once a minute

Or put something into /etc/profile.d and run at every shell startup, or put something into /etc/ld.so.conf.d and inject code into every process started on the system, or put something into /etc/init.d and run at every boot... (continue ad infinitum)

If you let code overwrite the files that make up your system configuration, you're going to have a Bad Time on any OS; this isn't somehow specific to Windows and the registry.

    /etc/inittab

You could probably replace the executables for the ttys, potentially having a keylogger for every userinput on the terminal?

Sure; the list of startup services is maintained there, for one (in one of a number of ways), but a variety of programs allow the administrator to configure hooks to execute when something happens as well. Then there are lists of variables that are in fact shell scripts, names of users’ configured shells, mount options, kernel modules, ... . Arbitrary code execution immediately (as opposed to after next reboot or at least a service’s configuration being reloaded) seems harder, but I expect it to be possible as well.

ETA: Took a couple of minutes, huh. A sibling comment mentions the dynamic linker, which apparently maintains a cache of well-known library locations in /etc. This yields execution as soon as a new dynamically linked executable is started, which probably qualifies as immediate. (More care would be required to avoid breaking the system in the process, though.)

This could be useful in places where you need to deliver something to someone who trusts you, but corp policies get in the way. I’m talking not maliciously. There a cases where you’re admin but still can’t quite run something, or download an exe, but this might get past.

They can't download an exe, but can download a .reg file, modify RunOnce, run powershell scripts, scripts that write an executable, and run that executable?

I mean, maybe that's a use case, sure, but I'm not likely to remember this is in my toolbox, much less assume it'll ever work.

why not executing the .exe and it doing it for you?

Reply on news.ycombinator.com