Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues
3APA3A wrote:
2. Conclusion:
[...]
hahaha. Seriously, the Windows security model is great and everything,
but it has never been used consistently, _never_. It's an uphill battle
Take privileges for example: 64-bit namespace and barely above a dozen
have been defined; two were overloaded and one recycled; and still no
way to create arbitrary privileges. So to implement capability checks
you perform group membership checks or make creative use of ACLs. Or
take default device security. Or how sandboxing inexplicably breaks
SSPI, making it close to useless. Or the countless hard-coded ACLs that
make the complexity of the whole thing so unjustified you wonder why
don't they just go with an "is administrator" bit. Or the total coolness
that is Safer, truly a few hooks short of a filesystem firewall, and how
criminally underused it is
Then there's the compatibility issues.
PGP Desktop breaks sandboxing rather spectacularly (silent crashes in
all sandboxed applications) because when its hook cannot open the shared
memory object (created with whatever default ACL was specified for the
PGPTray.exe process) it just tries to access the NULL pointer returned.
Sandboxing breaks the language bar - shared memory woes again. It has
the common decency of not crashing or worse, it just sorta limps along a
little. And the funny thing is, there _is_ a standard, documented way to
perform access checks compatible with GUI security boundaries (it's not
explicitely documented as such, but hey, we all come with a brain): all
processes in interactive sessions receive a special group ("logon id")
whose membership grants access to the display. It should be a _given_
for GUI hooks to use this mechanism, more so for GUI hooks developed by
Microsoft - but the language bar developers amply proved to be a bunch
of fucking cowboys anyway, and to Microsoft's credit they got it totally
wrong in the Windows 2000 version of runas, but fixed it for Windows XP
A long time ago I tried to advocate making all files in one's own user
profile non-executable by default, as a basic protection measure, and
like all the ideas I try to push, I dogfooded it extensively. It subtly
breaks a lot of innocent programs.
Other than completely isolating users, you cannot get any realistic form
of security. Isolating users from each other and from administrators is
the only scenario that has consistently been implemented and recognized.
The rest is a wasteland of abandoned technology and wishful thinking
The problem you describe? it has a 1-bit fix, SE_DACL_PROTECTED. All
files would be created by default with full access to owner and SYSTEM.
You can have fat lots of fun trying to figure out what will break and
how. A real solution would involve new DACL/SACL entries for directories
that enforce "acceptable" security descriptors on the files contained
therein. The same could work in the default DACL/SACL for tokens,
enforcing policies for *all* objects created by that subject (yes, I put
way too much thought in this. I am just gay for the Windows security
model. You can't not love a model where a subject might not belong to
the "world" group)
(ReadDirectoryChangesW on the other hand *is* a vulnerability, as it
gives traverse *and* list acces but only requests traverse)