Exploit Gets Around Windows' App Security Safeguards

[HardOCP News]

It's crazy that no one caught this vulnerability until now. No need for administrator access, no protection or any sort, just point Regsvr32 to a remote file and presto, you can make a system run any app you want.

Researcher Casey Smith has discovered a vulnerability in Windows that gets around this barrier. If you tell Regsvr32 to point to a remotely hosted file (such as a script), you can make a system run whichever app you want -- just what hackers and virus writers are looking for. It's stealthy, too, as it doesn't require administrator access or give itself away through registry changes.

 

[cyclone3d]

Very very interesting.

 

[DocSavage]

The article says this hack gets around white and blacklists. Though don't you need to run code to call regsevr32?

At least the link has a decent workaround using Windows firewall.

 

[Quartz-1]

I thought this was widely known, and widely used in corporate IT. I remember running installation scripts over a decade ago which used this to load stuff from network drives. I guess no one thought of the wider implications until now.

 

[Zarathustra[H]]

The article says this hack gets around white and blacklists. Though don't you need to run code to call regsevr32?

At least the link has a decent workaround using Windows firewall.

My understanding would be that this could be used by malware to install itself. If the user is tricked into executing something (say, from a browser or email) it can easily circumvent user permissions and install itself on the system.

Right?

 

[DocSavage]

My understanding would be that this could be used by malware to install itself. If the user is tricked into executing something (say, from a browser or email) it can easily circumvent user permissions and install itself on the system.

Right?

So a script already running on your computer can run a script? They didn't mention if this second script has privilege escalation.

 

[cyclone3d]

So a script already running on your computer can run a script? They didn't mention if this second script has privilege escalation.

Not really. Say you have a link in a browser or email that links to something like this:

file:///c:/windows/system32/regsvr32.exe (whatever commands to send to regsvr32 to execute remote code)

No way to block it except at the firewall.

 

[potency]

I've never understood the need for the registry. It doesn't do anything that can't theoretically be done in other, simpler, more secure ways.

 

[Deleted member 93354]

I've never understood the need for the registry. It doesn't do anything that can't theoretically be done in other, simpler, more secure ways.

You're not a programmer are you?

 

[potency]

You're not a programmer are you?

No, I've used the registry before for some small applications I've written just for the experience of utilizing it, and obviously it is at the core of how MS software works, but I've spent far more time chasing bugs and cleaning malware damage. The registry, like most of Windows, is bloated and unnecessarily complex. The vast majority of program settings, for example, could be stored simple .ini or .cfg files in the program's folder.

Also startup entries don't need to be in multiple places in the registry. They don't need to be in the registry at all for that matter.

 

[c3141hf]

You're not a programmer are you?

It is very obvious the people who invented the concept of the registry aren't. At least, not very good ones.

The registry is a mess. Not only are you putting all of your eggs in one basket, settings wise, but it is very difficult to properly backup and archive compared to textual configuration files.

 

[Deleted member 93354]

No, I've used the registry before for some small applications I've written just for the experience of utilizing it, and obviously it is at the core of how MS software works, but I've spent far more time chasing bugs and cleaning malware damage. The registry, like most of Windows, is bloated and unnecessarily complex. The vast majority of program settings, for example, could be stored simple .ini or .cfg files in the program's folder.

Also startup entries don't need to be in multiple places in the registry. They don't need to be in the registry at all for that matter.

The registry was designed to help with DLL Hell which was prevalent in windows 3.1. Program A works dll version 1 which is in system 32. Program B works with dll version 2 which is also in system 32. But guess what you broke dll version 1 when you overwrote it, breaking program A. Windows 3.1 used those wonderful .ini files you seem to be in love with. Editing binary in .ini files was also a nightmare.

The alternative option to dll hell is to have EVERY dll required to be packaged along with the program. And some of these DLL's are huge. But this doesn't solve problems for things like global handles, and atoms which require every dll be working on the same page.

.NET is changing a lot of that with .config files. (There is very little in terms of COM entries with .NET) But it does not remove the need for a registry

This is also one of the reasons corporate IT world is moving to the internet and using our computer as dumb terminals to access content. One machine that is validated to have the proper configs and binaries and uniformly handled via html/css/javascript etc.... (Well in theory). It's a lot easier than dealing with 5,000,000 different individual machine configurations.

 

[cyclone3d]

The registry was designed to help with DLL Hell which was prevalent in windows 3.1. Program A works dll version 1 which is in system 32. Program B works with dll version 2 which is also in system 32. But guess what you broke dll version 1 when you overwrote it, breaking program A. Windows 3.1 used those wonderful .ini files you seem to be in love with. Editing binary in .ini files was also a nightmare.

The alternative option to dll hell is to have EVERY dll required to be packaged along with the program. And some of these DLL's are huge. But this doesn't solve problems for things like global handles, and atoms which require every dll be working on the same page.

.NET is changing a lot of that with .config files. (There is very little in terms of COM entries with .NET) But it does not remove the need for a registry

This is also one of the reasons corporate IT world is moving to the internet and using our computer as dumb terminals to access content. One machine that is validated to have the proper configs and binaries and uniformly handled via html/css/javascript etc.... (Well in theory). It's a lot easier than dealing with 5,000,000 different individual machine configurations.

Ok, so what the crap is anything besides what is helpful/needed being put into the registry then?

Why does a single program need registry entries in 20+ places?

Put the stuff in the registry that needs to be there and leave the rest of the crap that software companies put in there out.

Maybe MS needs to enforce something where it will only allow absolutely necessary stuff in the registry. Everything else is completely blocked.

I too hate the cesspool that the registry has become.

 

[potency]

The registry was designed to help with DLL Hell which was prevalent in windows 3.1. Program A works dll version 1 which is in system 32. Program B works with dll version 2 which is also in system 32. But guess what you broke dll version 1 when you overwrote it, breaking program A. Windows 3.1 used those wonderful .ini files you seem to be in love with. Editing binary in .ini files was also a nightmare.

The alternative option to dll hell is to have EVERY dll required to be packaged along with the program. And some of these DLL's are huge. But this doesn't solve problems for things like global handles, and atoms which require every dll be working on the same page.

.NET is changing a lot of that with .config files. (There is very little in terms of COM entries with .NET) But it does not remove the need for a registry

This is also one of the reasons corporate IT world is moving to the internet and using our computer as dumb terminals to access content. One machine that is validated to have the proper configs and binaries and uniformly handled via html/css/javascript etc.... (Well in theory). It's a lot easier than dealing with 5,000,000 different individual machine configurations.

The registry is like Communism: It might sound good on paper to solve certain underlying issues, but in execution it just becomes one big, inefficient, convoluted, wasteful mess, that grows and corrupts with no oversight keeping it in check.

I agree that .NET is in many ways a better foundation for the world's dominant OS, but it's still built on a flawed design. And with most everything Microsoft, its execution is even worse. Remember how it was supposed to be backward compatible? Ha. Every release: deprecated, deprecated, new class, new class, deprecated, doesn't work quite the same way, new class. What's the point if so many specialized business apps require the installation of a specific version anyway?

 

[naib]

tried it... sure it will launch an application BUT it won't elevate the privileges.

 

[Ryokurin]

It is very obvious the people who invented the concept of the registry aren't. At least, not very good ones.

The registry is a mess. Not only are you putting all of your eggs in one basket, settings wise, but it is very difficult to properly backup and archive compared to textual configuration files.

That's overly simplifying it and clearly from someone who never had to deal with .ini files pre Windows 3.11. It biggest problems come from tons of 3rd party developers using it in ways it wasn't originally intended to be used. It's very similar to how everyone used to use the program files folder to dump dlls all over the place leading to the eventual slowdown from the machine due to dllhell.

 

[athenian200]

The registry was designed to help with DLL Hell which was prevalent in windows 3.1. Program A works dll version 1 which is in system 32. Program B works with dll version 2 which is also in system 32. But guess what you broke dll version 1 when you overwrote it, breaking program A. Windows 3.1 used those wonderful .ini files you seem to be in love with. Editing binary in .ini files was also a nightmare.

Linux and other Unix variants still have some of these problems to this day, because everything relies on configuration files and compile-time defaults rather than a central registry. They basically just expect people to recompile stuff against newer libraries (preferably one "blessed" version that is currently in vogue) and don't support multiple versions of the same library, in general. It's slowly getting better in some distributions. But seriously, there's one old program I have (SimCity 3000) that makes you specify a path to a specially compiled set of libraries every time you run it with LD_LIBRARY_PATH. Ugh.

They would just say, "Well, Program A is obviously broken and obsolete for relying on dll version 1, and needs to be recompiled against dll version 2."

This is also one of the reasons corporate IT world is moving to the internet and using our computer as dumb terminals to access content. One machine that is validated to have the proper configs and binaries and uniformly handled via html/css/javascript etc.... (Well in theory). It's a lot easier than dealing with 5,000,000 different individual machine configurations.

I kind of worry that that's where everything is headed eventually, even for home users. And that pretty much means we're back to the way things were before the PC... a lot of people relying on thin clients or dumb terminals, while a few organizations like schools, governments, or corporations have all the real computing power and applications. It essentially undoes the last several decades of work to put the power of a computer into people's hands, and asks us to relinquish control to people operating powerful mainframes all over again.

 

[pxc]

The article says this hack gets around white and blacklists. Though don't you need to run code to call regsevr32?

At least the link has a decent workaround using Windows firewall.

Yes. But less technical users may run a .sct file sent to them in email to get it going. And it's not like there are security problems with browsers :

There is a possible IOC in that any .sct files loaded onto the machine may be present in the "Temporary Internet Files" folder - c:\users\USER\appdata\local\microsoft\windows\temporary internet files\content.ie5\

I just blocked regsvr32.exe from both directories in Windows firewall.

 

[Ranma_Sao]

So in other words, you had code execute code. If I can run misc exe, and have it execute code, I executed code. This is not a vulnerability. If I had a code execution bug in a browser, the browser was already Whitelisted, so launching regsvr32 makes absolutely no sense. This whole thing is a non-issue. Having a user double click an SCT file, is no different than having the user double click a vbscript or macro, I had them execute code.

As to the registry, regsvr32 isn't for editing the registry, it's for registering COM objects. Com was done with configuation files before the registry in Windows 3.11. The registry is better, it's a database, it works better with low memory, it is cached, etc... it's not file based, settings can roam. IT has a lot of strengths.

It has some weaknesses as well, people really like human readable files. Machines don't, but people really do...

This posting is provided "AS IS" with no warranties, and confers no rights.