A comment on this article mentions a tool called "loadlibrary" used to discover this bug: https://github.com/taviso/loadlibrary. It allows fuzzing of Windows DLL files on Linux.
Recently I approached a software project with the idea that I'd like to employ a fuzzer later when possible. What I found particularly interesting is that as soon as I had this idea in my head, my mind would constantly think of the code in a defensive "I-need-to-account-for-any-input" way.
Not just thinking about making the code work in the desired way, but also that any other input is walled of.
I think fuzzers are something that should get more attention, because it doesn't just help find critical bugs, it also changes your mind-set to defensive programming.
I went to a computer camp as a child and my first project was a number guessing game where the computer would pick a random number and then tell you hotter and colder as you guessed numbers.
I passed it to a friend to show off my work, and the first number he entered was "a", crashing the program immediately. Defending against rogue inputs was literally the first thing I ever learned about writing safe code.
The teachers in my CS Labs would give us assignments that required reading all parameters from standard input. They would then run our code with /dev/random as input.
They didn't fail any project for failing this test, but it sure taught us a lesson on checking inputs and failing gracefully.
> Asked if Microsoft had previously fuzzed the Windows Defender component, a company representative said yes.
> "Fuzzing is one of a number of techniques we employ to update and strengthen our software," the representative said in an e-mail. "It is a standard practice we use as part of the Security Development Lifecyle for our products."
This journalist is naive. This answer says "sure we use fuzzing, but we have no idea if this particular bit of code was fuzzed." When you ask a binary question and a binary answer isn't provided, someone is usually trying to obfuscate the fact that they're on the wrong side of the binary.
That's awfully cynical. The answer they got is more indicative of the fact that they're talking to a representative rather than one of the engineers who would have actually been responsible for fuzzing it, so all the representative can really do is say what the policy is rather than answer the specific question of "was this particular component fuzzed"?
> This full system x86 emulator runs as SYSTEM, is unsandboxed, is enabled by default and remotely accessible to attackers.
Can anyone more familiar with these issues tell me why Microsoft is still running this stuff as SYSTEM? Seeing as Tavis has been poking holes in the same component for a couple of months now, I assume it's a design choice and there has to be some good reason for it. Right?
Windows is a rat's nest from hell when it comes to privilege separation. That was probably the only privilege level that allows it to communicate with what it needs to.
Even worse, despite this patch, it's still sitting here running as local system on my box. Total fucking nightmare.
Are you asking about Defender itself or the emulation component? I'd think that Defender does need the higher privilege level for obvious reasons, though conceivably the more "risky" emulation could be done in a separate process with reduced privileges. It would be a pretty big undertaking though; just consider e.g. DoS on a multi-user system by attacking the process with dropped privileges. Not saying it's infeasible, but I think it would be complex.
For defender to be able to do the kinds of things that AV does it has to run as system. Once you are running as SYSTEM what does "sandboxing" even mean?
Somehow you gotta give it to security researchers for slowly pushing the industry towards formally verified software. How long it is taking to even notice any change at all is a testament to how awkward (or at least peoples conception of how difficult) it must be to write formally verified software with current methods.
Or a testament to how little the industry actually cares about security once you ask them to actually put their money on the line.
Windows Defender was new in windows 10; there is no conceivable justification for using the kind of programming language that leads to this kind of vulnerability. But, here we are.
> At the same time, AV in many cases prevents infections that would otherwise prove costly, particularly for less experienced users who aren't likely to be individually targeted by state-sponsored hackers.
Is there evidence for this claim that is placed precariously at the end of an article full of detailed evidence for the exact opposite claim?
Well, most AVs just check icon + some data like sections, import table and only sometimes put some signatures on code. By using packer(not hard to find one) you can make almost any executable undetectable.
AV is such as losing battle. Whitelisting, developer vetting, and code signing (the IOS store...I know you guys hate it) are the only things that have shown to be a reasonable defense.
Also remember that on Windows 10, you cannot easily get rid of the insecure scanner. It will automatically reenable itself along with its insecure x86 emulator that runs as SYSTEM.
[+] [-] wouterinho|8 years ago|reply
[+] [-] Systemic33|8 years ago|reply
Not just thinking about making the code work in the desired way, but also that any other input is walled of.
I think fuzzers are something that should get more attention, because it doesn't just help find critical bugs, it also changes your mind-set to defensive programming.
[+] [-] amdavidson|8 years ago|reply
I passed it to a friend to show off my work, and the first number he entered was "a", crashing the program immediately. Defending against rogue inputs was literally the first thing I ever learned about writing safe code.
[+] [-] probably_wrong|8 years ago|reply
They didn't fail any project for failing this test, but it sure taught us a lesson on checking inputs and failing gracefully.
[+] [-] frandroid|8 years ago|reply
> "Fuzzing is one of a number of techniques we employ to update and strengthen our software," the representative said in an e-mail. "It is a standard practice we use as part of the Security Development Lifecyle for our products."
This journalist is naive. This answer says "sure we use fuzzing, but we have no idea if this particular bit of code was fuzzed." When you ask a binary question and a binary answer isn't provided, someone is usually trying to obfuscate the fact that they're on the wrong side of the binary.
[+] [-] eridius|8 years ago|reply
[+] [-] ferbivore|8 years ago|reply
Can anyone more familiar with these issues tell me why Microsoft is still running this stuff as SYSTEM? Seeing as Tavis has been poking holes in the same component for a couple of months now, I assume it's a design choice and there has to be some good reason for it. Right?
[+] [-] setq|8 years ago|reply
Even worse, despite this patch, it's still sitting here running as local system on my box. Total fucking nightmare.
[+] [-] mnarayan01|8 years ago|reply
[+] [-] dboreham|8 years ago|reply
[+] [-] youdontknowtho|8 years ago|reply
[+] [-] davidgrenier|8 years ago|reply
[+] [-] lmm|8 years ago|reply
Windows Defender was new in windows 10; there is no conceivable justification for using the kind of programming language that leads to this kind of vulnerability. But, here we are.
[+] [-] jancsika|8 years ago|reply
Is there evidence for this claim that is placed precariously at the end of an article full of detailed evidence for the exact opposite claim?
[+] [-] slezyr|8 years ago|reply
[+] [-] youdontknowtho|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] based2|8 years ago|reply
[+] [-] kevin_b_er|8 years ago|reply
[+] [-] hunterjrj|8 years ago|reply