A Windows Defender bug was so gaping its PoC exploit had to be encrypted

Post by hunterjrj » Tue, Jun 27, 2017, 2:45 PM UTC

Post by GoToRO » Tue, Jun 27, 2017, 2:56 PM UTC

lmm wrote: post #12

davidgrenier wrote: post #11

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.

Post by mnarayan01 » Tue, Jun 27, 2017, 2:59 PM UTC

SomeStupidPoint wrote: post #17

mnarayan01 wrote: post #15

Earlier quoted context omitted.

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 infeasibl…

> by attacking the process with dropped privileges In what way is this not strictly better for the defender than if that same process was running as SYSTEM? I don't think limiting the capabilities of a child process (even by running it as "SYSTEM_LITE") impacts its scheduling priority, security settings, etc. It would depend on the policy around the process.

Post by jdmichal » Tue, Jun 27, 2017, 3:09 PM UTC

amdavidson wrote: post #10

Systemic33 wrote: post #2

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…

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.

Post by lmm » Tue, Jun 27, 2017, 3:11 PM UTC

dsacco wrote: post #21

lmm wrote: post #12

Earlier quoted context omitted.

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.

Windows Defender has been around since Vista (XP, if you include systems it didn't ship with). More important than that nitpick - do you really see no conceivable justification for using C++? Really? None? The entire language is unsuitable for new development? And somehow, you captured this insight which managed to be overlooked by all the engineers working at Microsoft? What do you suggest we do? Gather the whole wo…