lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Sep 2007 16:09:26 +0100
From: Tim Brown <tmb@...35.com>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk, vuln-dev@...urityfocus.com
Subject: Re: [Full-disclosure] Next generation malware: Windows Vista's gadget API

Firstly, "the sky isn't falling, the risks posed by the gadget API already 
existed elsewhere in Windows generally, but this is another new attack 
surface without any legacy dependencies".  This is my general view on the 
gadget API.

On Sunday 16 September 2007 13:34:32 Thierry Zoller wrote:

> PG> No, this is an entirely new level of attack,
> "New level of attack", what makes you believe that?

As I previously stated, unlike Peter I don't consider this a new level of 
attack, I'm just a bit surprised that the threat model wasn't examined by 
Microsoft a little more closely before they decided to include the gadget 
API.  Unlike other APIs that Microsoft have released there was no legacy 
requirement to include all of the new functionality highlighted in my paper.  
Moreover, irrespective of the design decisions how did at least 3 Microsoft 
gadgets get through SDL without input validation being tested and the 
vulnerabilities.

> PG> because it's moved the dancing
> PG> bunnies problem onto the Windows desktop.
> Huh ? What is different to let's say the southpark worm we saw years
> ago? Or any other normal binary that promised to be a screensaver or
> similar ?

Because it's not just about downloading rogue gadgets.  I don't want to 
overhype the gadget API - it's just another attack surface after all - but if 
you look at all the PoCs so far, the greater risk comes from malware being 
injected into 'trusted' gadgets.

> PG> Given what an incredible attack vector they are
> What is incredible in this attack vector ? What is actually new ?
> What is the differnce with the  "User downloads screensaver and get's
> owned" attack vector ?

Allowing gadgets - trusted or otherwise - to download and execute arbitrary 
parts of the internet becomes a tad more dangerous when you explicitly allow 
them access to APIs for reading and write arbitrary files (subject to Vista 
ACLs) and executing  arbitrary binaries.  The process of securing IE has 
largely been to remove and mitigate such vectors by which this can occur, so 
why reintroduce them in non-legacy code.

Finally, why on earth does the trust model for gadgets consist of full trust 
and nothing more.  Why not allow gadgets to state in their manifest that for 
example they don't need to execute things, won't make use of ActiveX controls 
and will only connect to a specific host?

Tim
-- 
Tim Brown
<mailto:tmb@...35.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ