| Date: | August 7, 2007 / year-entry #288 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070807-00/?p=25683 |
| Comments: | 22 |
| Summary: | In the category of dubious vulnerability, I submit the following (paraphrased) report: I discovered that if I take an EXE file and corrupt its header, then when I try to run the EXE file, the process starts up and then crashes. I used the information in the crash dialog to direct further investigations, noting that... |
In the category of dubious vulnerability, I submit the following (paraphrased) report:
Yeah, that's great, but what's the vulnerability?
What you did was take a program that you have write permission to
and change the code in it to run your exploit.
If you can modify an EXE file, then you may as well just
replace the entire contents of the file with
the bytes of copy pwnz0rd.exe victim.exe Then when the user runs the infected program, they're really running
the In order to trigger the vulnerability, the user has to run the compromised program, but a program is already arbitrary code. No need to be so sneaky about it. It's sort of a tautology: "Here's my clever way to get the user to run my code. Step 1: Write some code. Step 2: Get the user to run it." Of course, if this corrupted EXE file created other types of problems, such as crashing Explorer or triggering a buffer overflow when the user tried to view its properties, then you'd be onto something. Or if you could somehow avoid detection by not altering the digital signature, then that'd be interesting as well. But if the only way to trigger code injection is to run the injected code, then that's not really all that interesting. You just found a roundabout way of creating a Trojan horse. |
Comments (22)
Comments are closed. |
Where’s the title line from – it sounds familiar but my feeble brain index refuses to find it…
Privilege escalation is another big one that you’ve mentioned in the past.
The title is from the Hitchikers Guide to the Galaxy:
"Well didn’t you think of anything? I thought you said you were going to think of something. Perhaps you thought of something and didn’t notice."
"Oh yes, I thought of something," panted Ford. Arthur looked up expectantly.
"But unfortunately," continued Ford, "it rather involved being on the other side of this airtight hatchway." He kicked the hatch they’d just been through.
My C compiler can produce similar code. When will Microsoft fix this?
Actually, Raymond, it’s a valid concern… for antivirus software (not operating systems, of course). It’s a family of techniques, collectively called Original Entrypoint Obfuscation (OEP), that can conceal where, exactly, the malicious code is hidden inside a trojaned/infected executable, making static analysis harder. I humbly suggest you just outed a legitimate, little-documented OEP technique :-)
When all you have is a hex editor…
Do you have any insights as to the thought processes of the submitter? They must in some sense have thought they were doing something different from ‘create program, run it’.
Hyperion, I’ve worked on legitimate applications of entrypoint obfuscation, and this isn’t even close. This is just someone coming to grips with the fact that executables are files and can be modified.
[slashdotter rant]
When I tie my computer to the bumper of my car with a rope then drag it down the road, all my data is laid bare for all the world to see.
I DEMAND to know when MS is going to fix this horrific and inexcusable zero-day exploit in Windows.
[/slashdotter rant]
JamesNT
JamesNT, I suggest you look into using Encrypting File Systems before dragging your computer along the road.
Regards,
Fred Freddington,
IT Security Consultant
PS. That will be $10,000, please.
JamesNT: Ever seen Zoolander?
pwnz0rd.exe… I chuckled. Thank you, Raymond, for this deconstruction of an absurd statement of the obvious.
"If can get the user to run code… then I can get the user to run code!" I can see it now: MS07-052: Code execution results in code execution.
Brilliant.
I’m disappointed there was nothing to put in the nitpicker’s corner. By freely admitting this, does it imply I’m a nitpicker?
"It’s… in the computer?"
It’s always funny (although also slightly depressing at the same time) to hear this kind of complete failure to grok security issues.
Also: HHTG quotes FTW! :)
nitpick re Miral’s last post: you’re missing at least one G, and possibly one T (depending on whether you believe you need a T for "the".
Raymond, you might want to read MS07-040, one of the critical vulnerabilities fixed is very similar your allegedly dubious vulnerability.
Also, given the mind boggling complexity of Windows, it is quite possible that a few of these allegedly non-security holes can be combined into a real security hole.
BTW, I happen to have seen part of the mail exchange between MSRC and the discoverer of the .NET PE Loader vulnerability and it took quite a lot of convincing before MSRC realized that there was a vulnerability. From the outside this (and your post here) looks very much like arrogance.
The critical difference with this "vulnerability" and MS07-040 is that in the PE Vulnerability, you are loading managed .NET code that escapes the sandbox and results in arbitrary code execution on the system. This is an escalation of privilege. In Raymond’s vulnerability, the user gains no additional privileges; they already had write access to the file.
Its like putting "del /q /s /f c:" in a batch file and then saying, "Look! This batch file erased my programs! Its vulnerable!" Of course it did. Thats what you TOLD it to do.
ps: When will Microsoft fix the newly discovered "DEL Command can erase files" vulnerability?
LOL, Just get UAC on the ball:
"You have opened an application. Do you want the program to run?" Allow/Deny
This idea is not quite original, but I think there still might be something in it.
Namely, if you as a regular (non-admin) user manage to modify an executable (say system service) and the modified copy gets loaded and executed on next reboot, then you can access the internet and do all sorts of other things you normally couldn’t.
Raymond said that it would be easier to overwrite a file, but if you overwrite say SPOOLSV.EXE and the user can’t print anymore you have just blown your cover.
One thing I must admit is that this “exploit” existed a long time ago, viruses used it extensively by inserting themselves into executables and after doing their work, they allowed the original program to run.
This is why Vista 64’s driver signing is pointless from a security standpoint. In order to load a rootkit, your Trojan must have administrator access already. If you have administrator access, you’ve already won.
Administrators that aren’t administrators – Microsoft might as well try to make water not wet.