Message-ID: <096A04F511B7FD4995AE55F13824B8332127FF@banneretcs1.local.banneretcs.com>
Date: Fri, 9 Mar 2007 13:14:05 -0500
From: "Roger A. Grimes" <roger@...neretcs.com>
To: "M. Burnett" <mb@...o.net>, "3APA3A" <3APA3A@...URITY.NNOV.RU>,
	<bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

But there is no difference in the treatment between this issue in Linux or Windows. In both systems, if I want to prevent attacks like this, I can do something ahead of time (i.e. umask or modify the Creator Owner SID, or inheritance). Only OpenBSD (and other BSD and hardened Linux's) do a better job by having a better default Umask. But in the typical Linux distro, I have to set the umask. He makes up a scenario of placing a secure folder insider of an insecure folder, and I'm somehow supposed to accept that as normal?

Mark, I respect you and your work greatly. I like a lot of 3APA3A's ideas and concerns....but they aren't in the realm of a real security concern.  Real security concerns are when I can't do anything with the default OS to stop the weird attack they mention. In this case, there are plenty of things I can do.  I don't have to buy software or be a security genius. I just have to not place a "secure" folder in an insecure folder.  

Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes@...oworld.com or roger@...neretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: M. Burnett [mailto:mb@...o.net] 
Sent: Friday, March 09, 2007 12:44 PM
To: Roger A. Grimes; '3APA3A'; bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

> But we'll have to agree to disagree. Your security scenarios are just 
> bizarre. It's a lot easier to hack people then going through all the 
> interations you suggest.

Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability based on current scenarios because we really can't begin to imagine how these things might be exploited in future attacks. For example, the attack of deleting someone's folder and re-creating it before they set permissions sounds bizarre until someone makes a tool that does that automatically to all new folders. It changes everything when even the front desk secretary can pull off the attack. 

And even if it would be lame for someone to set up a folder where this would be possible, people will still set up folders where this is possible. It's important for us to be aware of the risks of these configurations. And you have to admit, it is pretty amazing he found something we all missed for the last ten years, despite how simple it is. 
 
Finally, I don't think 3APA3A is over hyping this issue beyond what it really is. He acknowledges that it isn't really a vulnerability and he's not submitting press releases to all the mainstream media. He gave Microsoft fair notice and awaited their decision and he's not screaming that everyone must abandon Windows. But he is informing the security community of something that we certainly should be aware of. 


Mark Burnett
http://xato.net

 
> For one, I've been a sys admin for 20 years and NEVER created a 
> private folder under a public folder. Not in my Novell days, not in my 
> Windows days. The only time I've seen a private folder created under a 
> public folder is the \Users folder, and in that case, the users only 
> have Read and List access to the parent \Users folder, and then Full 
> Control to their own folders.
> 
> I mean let's debate why users get Full Control to their own folders in 
> the first place. That's a common scenario (it's on nearly every
> network) and its almost always too many permissions. Do I want my 
> regular end-users changing their folder's security permissions? No.
> Should any regular end-user have Full Control to any share? No, for 
> the same reason.  These are valid, common, security points that really 
> do beg further discussion.
> 
> You're just making up crap up that isn't overly realistic in the 
> world, then going further to assume that a bonehead administrator 
> compounds the problem by making further insecure decisions.
> 
> You are essentially say, "If you misconfigure your system and make 
> further insecure choices, someone can hack you." Duh.
> 
> There's a reason why your "announcements" aren't making the news 
> media...because it isn't news.
> 
> With that said, you have something valid to say, but so far it just 
> isn't a "security vulnerability" that people need to be aware of.
> 
> You're a smart person, concentrate on issues that will really give us 
> bang for the buck discussions and issues.
> 
> Roger
> 
> *****************************************************************
> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE: 
> Security (2000/2003/MVP), CEH, yada...yada...
> *email: roger_grimes@...oworld.com or roger@...neretcs.com *Author of 
> Professional Windows Desktop and Server Hardening (Wrox)
> *http://www.amazon.com/gp/product/0764599909
> *****************************************************************
> http://winblogs.security-feed.com
> Server Hardening, NTFS
> -----Original Message-----
> From: 3APA3A [mailto:3APA3A@...URITY.NNOV.RU]
> Sent: Friday, March 09, 2007 7:09 AM
> To: Roger A. Grimes
> Cc: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
> Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management 
> security issues
> 
> Dear Roger A. Grimes,
> 
> --Friday, March 9, 2007, 7:31:54 AM, you wrote to
> 3APA3A@...URITY.NNOV.RU:
> 
> RAG> If Alice deletes Bob's folder (which she could do in some
> scenarios
> RAG> because she has the write/modify permission) and re-creates it,
> she
> RAG> becomes  the Creator Owner and now Bob no longer has the ability
> to
> RAG> set permissions on it.
> 
> As a folder owner Alice can give any permissions to Bob she wants.
> 
> RAG> If I take your strange assumptions, Bob could re-discover the
> newly
> RAG> created folder that Alice made, just like she did (I mean if you 
> RAG> make up crap scenarios, why can't I), and do the same trick back
> to her.
> 
> He can, if he knows he must.
> 
> RAG> And Windows does have a umask-like function. It's called Creator
> Owner.
> RAG> It's a well known SID, and the default permissions for it can be 
> RAG> set so that any granular permission you want can be set to be
> default.
> 
> I  see  nothing  similar  between Creator Owner and umask. BTW, the 
> same article  explains  why  Creator  Owner  is not 100% solution and 
> why you should not rely on Creator Owner in case of DFS replication.
> 
> RAG> Vista does have symbolic links, and Windows has supported 
> RAG> Junction Points (similar to symbolic links) since Windows 2000. 
> RAG> The main difference is that Junction Points could only point to 
> RAG> local resources and symbolic links can do remote resources as well.
> 
> Junction  points are very close to Unix mounts, I see no any likeness 
> to symbolic  links.  Junctions  points  (and  by default, symbolic 
> links in
> Vista)  can  only  be  created  by  administrators,  it prevents 
> symlink attack. And it's right choice.
> 
> RAG> You've come up with some strange scenarios below, and in all 
> RAG> cases I could easily defeat the problem you are suggesting by 
> RAG> using basic, recommended, security settings.
> 
> 
> "You never know what is enough unless you know more than enough."
>                                                     William Blake
> 
> It's  quite  hard  to defeat the threat without knowing it. I'm 
> disagree with  you about "recommended security settings". I never saw 
> "disconnect all  users and close access to the share" or "check you 
> are still folder owner before copy the data" in instructions on how to 
> create file/folder with restricted access inside public one. Or "xcopy 
> /O doesn't guarantee file  can  not  be  accessed  during  copy 
> operation" or "Do not rely on Creator Owner in case of replication".
> 
> RAG> Why  do  you spend your time coming up with such weird scenarios
> to
> RAG> focus  on?
> 
> Roger,  have  you  ever  used  robocopy  or  xcopy  /O? I'm not 
> security columnist,  I  am  system  administrator/engineer.  For  last 
> 10 years I
> develop   and   implement  a  lot  of  corporate  directory
> structures,
> replications,  and  backup/restore  policies  for  many  very 
> different organizations.  I explain mistakes I can personally make and 
> sometimes I personally  did (mixing secure and insecure data, 
> implementing automatic replication  to  unprotected folders, 
> implementing data restore policies where  user  can  ask  system 
> administrator  to  restore some directory structure  to  user 
> accessible folder, etc). May be I'm only dumb person who  does 
> mistakes  like  that,  most probably not. I call it "properly placed 
> rakes to step on".
> 
> RAG> You're  obviously  a  creative  guy  with  some Windows security 
> RAG> smarts.
> 
> Thanks.
> 
> RAG> Why  not  focus on more realistic scenarios with more  real-world 
> RAG> use? There's plenty of them for us to focus on and to try and 
> RAG> solve.
> 
> Roger,  of  cause  next  time  I  should  concentrate on a single- 
> packet exploitable overflow in IPv6 stack to interest InfoWorld 
> readers. I will not,  because  it's  nothing interesting for me in 
> searching yet another buffer  overflow.  Let  another  creative  guys 
> who are professional in vulnerability  researching  to  dig it. They 
> have tools, time and money.
> For me, most valuable vulnerability is one simple enough to be 
> exploited with notepad, because it can be noted by everyone, but was 
> unnoticed for 10 years.
> 
> RAG> Roger
> 
> RAG> *****************************************************************
> RAG> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE:
> RAG> Security (2000/2003/MVP), CEH, yada...yada...
> 
> 3APA3A. MCSE/MCT since Windows NT 4.0.
> 
> RAG> *email: roger_grimes@...oworld.com or roger@...neretcs.com 
> RAG> *Author of Professional Windows Desktop and Server Hardening 
> RAG> (Wrox)
> RAG> *http://www.amazon.com/gp/product/0764599909
> RAG> *****************************************************************
> 
> 
> RAG> -----Original Message-----
> RAG> From: 3APA3A [mailto:3APA3A@...URITY.NNOV.RU]
> RAG> Sent: Thursday, March 08, 2007 2:59 PM
> RAG> To: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
> RAG> Subject: Microsoft Windows Vista/2003/XP/2000 file management 
> RAG> security issues
> 
> 
> RAG> This   is   an   article   I   promised   to   publish   after
> Windows
> RAG> ReadDirectoryChangesW  (CVE-2007-0843)  [1] issue. It should 
> RAG> explain why you must never place secure data inside insecure
> directory.
> 
> 
> 
> RAG> Title: Microsoft Windows Vista/2003/XP/2000 file management 
> RAG> security issues
> RAG> Author: 3APA3A, http://securityvulns.com/
> RAG> Vendor: Microsoft (and potentially another vendors)
> RAG> Products:  Microsoft  Windows Vista/2003/XP/2000, Microsoft
> resource kit
> RAG>            for Windows 2000 and different utilities.
> RAG> Access Vector: Local
> RAG> Type: multiple/complex (weak design, insecure file operations,
> etc)
> RAG> Original advisory:
> http://securityvulns.com/advisories/winfiles.asp
> RAG> Securityvulns.com news:
> RAG> http://security.nnov.ru/news/Microsoft/Windows/files.html
> 
> RAG> 0. Intro
> 
> RAG> This  article contains a set of attack scenarios to demonstrate 
> RAG> security weakness in few very common Windows management practices.
> RAG> Neither of the problem  explained  is critical, yet combined
> together they should force
> RAG> you   to   review   your   security   practices.   I   can't  even
> say
> RAG> "vulnerabilities"   because   there   is   no  something  you can
> call
> RAG> "vulnerability". It's just something you believe is secure and
> it's not.
> 
> RAG> 1.1 Problem: inability to create secured file / folder in public
> one.
> RAG>     Attack: folder hijack attack
> 
> RAG> First,  it's simply impossible with standard Windows interface to 
> RAG> create something secured in insecure folder.
> 
> RAG>  Scenario  1.1:
> 
> RAG>  Bob  wishes  to  create "Bob private data" folder in "Public"
> RAG> folder to place  few private files. "Public" has at least "Write"
> RAG> permissions for "User" group. Bob:
> 
> RAG>      I   Creates "Bob private data" folder
> RAG>      II  Sets permission for folder to only allow access to 
> RAG> folder himself
> RAG>      III Copies private files into folder
> 
> RAG>   Alice wants to get access to folder Bob created. She
> 
> RAG>      Ia  Immediately  after  folder  is  created,  deletes "Bob
> private
> RAG>          data"  folder  and creates "Bob private data" folder
> again (or
> RAG>          simply  takes  ownership  under  "Bob  private data"
> folder if
> RAG>          permissions allow). It makes Alice folder owner.
> RAG>      IIa Immediately  after  Bob  sets permissions, she grants
> herself
> RAG>          full control under folder. She can do it as a folder
> owner.
> RAG>      IIIa  Reads  Bob's  private  files,  because  files
> permissions are
> RAG>          inherited from folder
> 
> RAG>   Alice   can  use  "Spydir"
> RAG> (http://securityvulns.com/soft/)  tool  to
> RAG>   monitor  files  access  and automate this process. As you can
> see, [1]
> RAG>   elevates this problem significantly.
> 
> RAG>   This   is  not  new  attack.  Unix  has  "umask"  command  to
> protect
> RAG>   administrators and users. Currently, Windows has nothing
> similar.
> 
> RAG>   CreateFile() API supports setting file ACL on file creation
> (just like
> RAG>   open()  allows  to set mode on POSIX systems). ACL can be
> securely set
> RAG>   only  on  newly  created  files.  This raises a problem of
> secure file
> RAG>   creation.
> 
> RAG> 1.2  Problem: Inability to lock / securely change permissions of
> already
> RAG>      created file
> RAG>      Attack: pre-open file/directory attack.
> 
> RAG>   There  are  few  classes  of insecure file creation attack
> (attempt to
> RAG>   open   existing  file),  exploitable  under  Unix  with
> hardlinks  or
> RAG>   symlinks.  It's  believed  Windows  is  not vulnerable to this
> attacks
> RAG>   because
> 
> RAG>     I.  There  is  no  symlinks  under Windows. Symlink attacks
> are not
> RAG>         possible.
> RAG>     II. Security  information  in  NTFS  is  not  stored  as  a
> part of
> RAG>         directory entry, it's a part of file data. Hard link
> attacks are
> RAG>         not possible.
> RAG>     III. File  locks  in  Windows  are  mandatory.  It  means,  
> RAG> if
> one
> RAG>          application  locks  the file, another application can 
> RAG> not
> open
> RAG>          this  file, if user doesn't have backup privileges. It
> mitigate
> RAG>          different file-based attacks.
> 
> RAG>   There  is at least one scenario, attacker can succeed without
> symbolic
> RAG>   link:  to  steal  data  written to file created without check
> for file
> RAG>   existence regardless of file locks and permissions.
> 
> RAG>   Attack description: if attacker can predict filename to be
> written, he
> RAG>   can  create file, open it and share this file for all types of
> access.
> RAG>   Because  locking  and  permissions  are  only  checked  on  
> RAG> file
> open,
> RAG>   attacker  retain  access  to  the  file  even  if it's locked
> and it's
> RAG>   permissions are changed to deny file access to attacker.
> 
> RAG>   Exploit (or useful tool):
> RAG> http://securityvulns.com/files/spyfile.c
> 
> RAG>   Opens  file, shares it for different types of access and logs
> changes,
> RAG>   keeping the file open.
> 
> RAG>   Compiled version is available from
> http://securityvulns.com/soft/
> 
> RAG>   Scenario 1.2.1:
> 
> RAG>    Bob is now aware about folder hijack attack. He use xcopy /O 
> RAG> /U
> /S to
> RAG>    synchronize  his  files  to  newly  created  folder.  xcopy /O
> copies
> RAG>    security  information (ownership and permissions) before
> writing data
> RAG>    to file.
> 
> RAG>    Alice  use  "Spydir"  to  monitor  newly created folders and
> files in
> RAG>    Bob's  directory.  She  use Spyfile to create spoofed files in
> target
> RAG>    directory  and  waits for Bob to run xcopy. Now, she has full
> control
> RAG>    under  content of Bob's files despite the fact she has no
> permissions
> RAG>    to access these files.
> 
> RAG>    In  a  same  way  directory  content  may be monitored by pre-
> opening
> RAG>    directory.
> 
> RAG>   Scenario 1.2.2:
> 
> RAG>    Enterprise  directory  structure  is  replicated every day to
> another
> RAG>    user-writable  location  in  order  to alow users to recover
> suddenly
> RAG>    deleted  or  modified files. xcopy or robocopy (from resource
> kit) is
> RAG>    used  for  replication.  Attacker can hijack content of newly
> created
> RAG>    files in newly created folders.
> 
> RAG>   Same problem may happen on archive extraction or backup
> restoration.
> 
> RAG>   Vulnerable  applications:
> RAG>     xcopy (from all Windows versions),
> RAG>     robocopy (Windows  2000  Resource Kit),
> RAG>     different archivers
> RAG>     backup restoration utilities
> 
> RAG>   By  default,  xcopy warns user the file exists, unless /Y or /U
> key is
> RAG>   specified.  But
> RAG>     I.  /Y  is  always  specified  for replication
> RAG>     II. /Y  can  be specified via COPYCMD environment variable.
> COPYCMD
> RAG>     environment    variable   can  be  created  in  autoexec.bat
> file.
> RAG>     Different situations are possible, where autoexec.bat is
> writable by
> RAG>     attacker, if:
> RAG>      - Default Windows 2000 permissions are used or applied with
> domain
> RAG>      policy [2].
> RAG>      - One can try to re-create autoexec.bat using POSIX subsystem
> RAG>     III.  Neither  xcopy  nor  other  utilities  warn user on
> existing
> RAG>     directory. Pre-open directory attack will always succeed.
> 
> RAG>   As you can see, [1] again dramatically elevates this problem.
> 
> RAG> 1.3 Problem: user can completely block access to the files
> RAG>     Attack: open file deletion
> RAG>     (including Windows file replication service DoS)
> 
> RAG>     If files is deleted while it's open, it still present in file
> system
> RAG>     under  it's  old  name  until  close.  Any  operation  on 
> RAG> this
> file
> RAG>     (including  attributes  requests)  fails,  regardless of
> application
> RAG>     rights and permissions (including backup ones).
> 
> RAG>     Exploit:  use  spyfile,  delete  file while it's spied. Now,
> without
> RAG>     closing  spyfile,  attempt  any  operation on this file (e.g.
> try to
> RAG>     find it's ownership).
> 
> RAG>     Scenario 1.3.1
> 
> RAG>     Now Bob found an copy application to securely copy files. It
> deletes
> RAG>     old file before creating new one. But it fails if Alice tries
> to spy
> RAG>     on  Bob  files,  because  attempt  to delete file succeeds,
> but file
> RAG>     still present and is unmanageable.
> 
> RAG>     Scenario 1.3.2
> 
> RAG>     Windows  file  replication  service  (FRS) is used to
> replicate data
> RAG>     between  2  public  DFS  folders  to  distribute  load.
> Folder  has
> RAG>     permissions:
> RAG>      Everyone: Add & read
> RAG>      Creator Owner: Full Control
> RAG>     Thouse, Alice has no permissions to delete files created by
> Bob.
> 
> RAG>     Replicated  folder  is  available as a share on 2 different
> servers:
> RAG>     \\SERVER1\Share    and    \\SERVER2\Share.    Bob    is
> connected
> RAG>     to \\SERVER1\Share.
> 
> RAG>     Alice uses "Spydir" to monitor files creation by Bob. Every
> time Bob
> RAG>     creates  new  file  on  \\SERVER1\Share, Alice use spyfile to
> create
> RAG>     file  with same name on \\SERVER2\Share. It effectively leads
> to FRS
> RAG>     collision.  While  trying  to resolve collision, FRS fails to
> delete
> RAG>     file  created  by  Alice  and  Bob file is deleted (original
> file is
> RAG>     moved to special hidden folder only accessible by
> administrator).
> 
> RAG>     Workaround:  never  try  to  use  creator-owner based
> permissions in
> RAG>     replicated folders.
> 
> RAG>     Again, [1] seriously escalates this problem.
> 
> RAG> 2. Conclusion:
> 
> RAG>   It's  simply impossible to securely create something in public
> folder.
> RAG>   At least DoS conditions are always possible.
> RAG>   Developers should  not  consider mandatory file locking as a
> security
> RAG>   feature.
> RAG>   Developers  should  care about secure file creation to store
> sensitive
> RAG>   information.  CREATE_NEW  should  always be used and ACL should
> be set
> RAG>   with  lpSecurityAttributes  of CreateFile. No attempt to open
> existing
> RAG>   file should be made.
> RAG>   Never  try  to  create secure folder in public one. If you are
> forced,
> RAG>   disconnect     all   users   before   this   operation.
> RAG>   Never  use  replication,  archive  extraction  or  backup
> restore  to
> RAG>   user-accessible folder.
> RAG>   Bob and Alice should finally marry.
> 
> RAG> 3. Vendor:
> 
> RAG>   All timelines are same with [1].
> 
> http://passwords.security-feed.com
> RAG> [1]. Microsoft Windows ReadDirectoryChangesW information leak
> RAG> (CVE-2007-0843)
> RAG> http://security.nnov.ru/news/Microsoft/Windows/ReadDirector.html
> RAG> [2]. Windows 2000 system partition weak default permissions 
> RAG> http://securityvulns.ru/news2205.html
> http://xato.net
> RAG> --
> RAG> http://securityvulns.com/
> RAG>          /\_/\
> RAG>         { , . }     |\
> RAG> +--oQQo->{ ^ }<-----+ \
> RAG> |  ZARAZA  U  3APA3A   } You know my name - look up my number (The
> RAG> Beatles)
> RAG> +-------------o66o--+ /
> RAG>                     |/
> 
> 
> 
> --
> ~/ZARAZA http://securityvulns.com/
> Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. 
> (Лем)

Powered by blists - more mailing lists