A Windows Defender bug was so gaping its PoC exploit had to be encrypted
1–10 of 41 posts
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#2Recently 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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#3> 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?
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#4Recently 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…
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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#5> 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?
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#6> 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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#7A 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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#8> 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?
Wondered that myself a couple of months ago when this first came up. I assumed: bacuase thoughtless, but perhaps there's an actual reason.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#9> 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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#10Recently 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.