bugtraq - RE: "run as" local denial-of-service enables administrative account processes to be killed

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: <ED4D2B7262D0FF46B802B35FF362FE680179CD62@lincoln.fairfax.phra.com>
Date: Tue, 26 Jun 2007 10:30:18 -0400
From: "James C. Slora Jr." <james.slora@...a.com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>
Subject: RE: "run as" local denial-of-service enables administrative account processes to be killed

Eitan Caspi wrote Saturday, June 23, 2007 4:45 PM

> Summary: While a user, at any security membership level, is logged 
> in locally, using the "run as" feature, it can kill all of the 
> processes running under the user who initiated the "run as"
> feature, even if the
> initiating user has a security membership level higher than the 
> user initiating the killing action under "run as". The kill is 
> performed using the taskkill.exe application which is built into 
> Windows XP.

It's true Microsoft does not display a unified front on such security
issues, and they sometimes have conflicting advice on their site.

But Runas is more useful for escalating privilege than for downgrading
it.

Anything running on your interactive desktop can interact with anything
else running on it, regardless of the security context that started each
app. So privilege-lowering conveniences like Runas or even desktop VMs
are absolutely subject to the possibility of cross-context interaction.

There are security context checks built into many functions, and you did
find one that does not have things as locked down as they should be, but
these locks and checks are vector-specific and do not address the basic
exploit potential directly.

I don't see a lot of exploits of this potential, but it is designed into
Windows and needs to be there for you to be able to interact with the
apps yourself. So running an interactive sandbox on a trusted system
will inherently increase your risks.

See KB327618 for more info.

- Jim