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] [day] [month] [year] [list]
Message-ID: <1359285136.20070311003242@SECURITY.NNOV.RU>
Date: Sun, 11 Mar 2007 00:32:42 +0300
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: "Thor (Hammer of God)" <thor@...merofgod.com>
Cc: bugtraq@...urityfocus.com,
	"Roger A. Grimes" <roger@...neretcs.com>,
	"Tim" <tim-security@...tinelchicken.org>,
	<full-disclosure@...ts.grok.org.uk>
Subject: Re[2]: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

Dear Thor (Hammer of God),

 You are wrong at least for Windows XP/2003. There is a common temporary
 directory

 %WINDIR%\Temp

 It's  used  as a %TEMP% if application is launched without local logon,
 e.g. system service.

 For  example, services launched with LocalSystem account will have this
 environment variables:

SystemRoot=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
USERPROFILE=C:\Documents and Settings\LocalService
 

 You  can  find  it's really used, because it's never empty. I see, e.g.
 files  related  to  different  Intel  drivers,  VMWare,  Microsoft .Net
 framework, Exchange and Sharepoint.

 Also,  I  remember  I  had  problems with securing ABN AMRO Bank client
 software installation, because it uses %WINDIR%\Temp for some reason.

 And now is most exciting: Users have permission to create files in this
 directory, that is pre-open attack is possible.

--Saturday, March 10, 2007, 7:28:27 PM, you wrote to bugtraq@...urityfocus.com:

THoG> Apps utilizing temporary files should always use the TEMP or TMP environment
THoG> variables, not a hard-coded path.  And by default, each user has their own
THoG> temp directory created (in XP/Server it is "\Documents and 
THoG> Settings\username\Local Settings\temp" and in Vista it is 
THoG> "\Users\username\AppData\Local\Temp") that only they have permissions to
THoG> (with SYSTEM and Administrators, of course).  It's not like there is some
THoG> global "Full Control" temp directory created by default.

THoG> t



THoG> ----- Original Message ----- 
THoG> From: "Roger A. Grimes" <roger@...neretcs.com>
THoG> To: "Tim" <tim-security@...tinelchicken.org>
THoG> Cc: <bugtraq@...urityfocus.com>;
THoG> <full-disclosure@...ts.grok.org.uk>
THoG> Sent: Friday, March 09, 2007 9:42 AM
THoG> Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
THoG> management security issues


THoG> So, let me get this. An app storing sensitive data doesn't make its own
THoG> temp storage folders in a secure location, and instead relies upon one
THoG> of the few folders in Windows that all users have Full Control to, and
THoG> this is a Windows problem?  In Linux, if an app uses \tmp, is that a
THoG> Linux issue?

THoG> Sounds like a developer issue to me.

THoG> Roger

THoG> -----Original Message-----
THoG> From: Tim [mailto:tim-security@...tinelchicken.org]
THoG> Sent: Friday, March 09, 2007 11:20 AM
THoG> To: Roger A. Grimes
THoG> Cc: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
THoG> Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
THoG> management security issues


THoG> I find your assessment somewhat short-sighted.  I have conducted code
THoG> reviews on several commercial apps which use C:\TEMP in very insecure
THoG> ways to store sensitive data.  It seems some of these attacks would be
THoG> possible in those situations.

THoG> Sure, Windows is already pathetically insecure against an attackers
THoG> already on the local system, but this would be yet another attack
THoG> vector.

THoG> tim




-- 
~/ZARAZA http://securityvulns.com/
ÝÍÈÀÊàì - ïî ìîðäå!  (Ëåì)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ