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.
A Windows Defender bug was so gaping its PoC exploit had to be encrypted
11–20 of 41 posts
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#12Somehow 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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#13Somehow 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.
> Windows Defender was new in windows 10
According to Wikipedia (https://en.wikipedia.org/wiki/Windows_Defender) it was first released for Windows XP.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#14Somehow 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.
I feel that, for the end-user business at least, security is both a gamble (you may never be targeted at all) and being totally safe seems unreachable therefore stakeholders spend symbolic amount of resources to feel good about themselves.
Windows Defender is present on my Win7 installation.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#15> 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?
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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#16Somehow 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.
> no conceivable justification for using the kind of programming language that leads to this kind of vulnerability
The legacy tail is longer than you think.
Microsoft have started moving things towards C#, but generally in order to do things on Windows the only sensible option is C++. Even if you write your app in something else you'll end up having to deal with pre-existing DLLs that have the usual issues.
Really the Morris Worm should have been more of a wakeup, but in a world where there's no external liability for insecurity the commercial and market pressure is towards whatever gets the app built and saleable, with security trailing behind.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#17> 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?
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.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#18Somehow 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.
Windows Defender was introduced as an antispyware in Windows Vista. Antivirus functionality was initially available separately as a part of Security Essentials, which was merged with Defender for the Windows 8 release.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#19Earlier 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 was new in windows 10 According to Wikipedia ( https://en.wikipedia.org/wiki/Windows_Defender ) it was first released for Windows XP.
Yes, as Microsoft Security Essentials.
Re: A Windows Defender bug was so gaping its PoC exploit had to be encrypted
#20> 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.
Which is why most av products will flag any upx or mpress binary as "Trojan unknown" etc.
They mostly use a whitelist approach to work around that. Ask me how I know sometime.