From: amores p. <lif...@ho...> - 2005-10-22 17:23:59
|
>From: Earnie Boyd <ea...@pr...> >Subject: Re: [Mingw-users] MinGW 5.0.0 installer feed back >Date: Sat, 22 Oct 2005 12:53:08 +0000 > >Quoting amores perros <lif...@ho...>: > >> >> >> >>>From: Earnie Boyd Subject: Re: [Mingw-users] MinGW 5.0.0 installer feed >>>back >>>Date: Fri, 21 Oct 2005 12:12:24 +0000 >>> >>>Quoting amores perros <lif...@ho...>: >>> >>>> >>>>I was rather surprised that an ordinary user can create a new >>>>subdirectory off of the system root (C:\) in Windows XPSP2, >>>>out of the box. Apparently there is an ACL entry for allowing >>>>anyone to append, on the root. >>>> >>>>Even more surprisingly to myself, I see what I think is the >>>>same situation on a 2003SP1 server (not integrated SP1): >>>> >>>>cacls c:\ >>>>... >>>>BUILTIN\Users:(CI)(special access:) >>>> FILE_APPEND_DATA >>>> >>>>BUILTIN\Users:(CI)(IO)(special access:) >>>> FILE_WRITE_DATA >>>> >>>> >>>>But I'm off-topic. >>>> >>> >>>Yes we certainly are, but since you're so surprised; you may be even more >>>surprised to know that you can access remotely the root of any drive on >>>any >>>server as a mapped drive on your client. All you need to know is the >>>host name >>>of the PC you wish to connect to. E.G.: \\yourserver\C$ mapped to z:. >>>When a >>>PC boots the default behavior is for the root of all drives attached to >>>be >>>shareable with a share name equal to the drive letter. >>> >> >>That contradicts Microsoft's documentation on the >>subject, which I have assumed is correct. >> >>Here is a sample: >> >>http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prde_ffs_mgte.asp >> >>(assuming that a url to an article on a Microsoft site can stay >>valid for long enough for you to click it -- they seem to break >>their own urls amazingly rapidly). >> >>They say -- and I believe they've long said -- that those >>are not accessible to just any client, but to only >>members of the local Adminstrators group (as one >>would expect), although I've also seen it claimed >>that they're accessible to members of the >>local Backup Operators group as well. >> > >The document didn't use the word local. I've never experienced any problem >accessing what MS is calling an Administrative Share from a remote computer >unless steps were taken to prevent it after the computer was rebooted or >Server >service was restarted. The prevention steps must be taken upon each reboot >and >do not persist with shutdown. > Its fundamental to how named pipes work that the relevant group token is the one local to the SAM at the Server -- it is always thus. The SAM at the Server may include a domain SAM (and thereby, trusted domains as well), which means it will look up info in a Global Catalog (that is like a Domain Controller from NT). Possibly you are using shared passwords & accounts on different machines? Or possibly you are using a domain admin account and the server is in the domain? The Windows security model never protects against domain admins (like root, they are trusted to do absolutely anything, in general terms) -- and -- (and this may surprise you, if you've no experience with it) -- it also does not protect against users who use the same accountname and password in different SAMs (that means, security databases, either different machines or different domains). Can you reproduce access to Server A from client B, with an account on client B which is not mapped in to the local admin group on Server A (and, btw, if Server A is in a domain, then by default the Domain Admins for the domain are mapped into the local admin group on Server A -- not sure if you knew that), and also is not a reused username/password from an account on Server A which is in the local admin group? If so, I'm most interested in it, and I think it is a HUGE hole in Windows security? Inquisitively, Perry |