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] [thread-next>] [day] [month] [year] [list]
From: prp17 at adelphia.net (Phillip R. Paradis)
Subject: IE is just as safe as FireFox

> >>Wouldn't such a tool be of limited utility, given that the 
> unpriviliged
> >>application's windows are on the same desktop as, and can 
> therefore send
> >>messages to, windows belonging to priviliged applications?
> >>    
> >>
> Correct.
> Damn no ways out, this is flawed.
> Is that new ? No.

IIRC, this was discussed long ago on NTBUGTRAQ when Win2k was released, and
people thought about using RunAs to run applications with an unpriviliged user
while logged in as an administrator, with the same conclusion.

Arguably, the same vulnerability exists when using RunAs to execute a process
with admin rights while logged in as an unpriviliged user, but it would be
harder to predict when the system is vulnerable. When logged in as admin, there
is always a window attached to a priviliged process somewhere; namely, the
desktop, taskbar, etc, whereas when logged in as a peon and using RunAs for
admin rights when needed, this is not the case; priviliged applications are
running only part of the time and there is no common target; methods for
attacking a control panel applet in this manner will likely differ from methods
used to attack, say, MMC, while things are easier if you know there will always
be a taskbar or desktop to attack. Also, when using RunAs to elevate privilige
when needed, rather than to drop privilige, the danger can be mitigated by
closing the priviliged process prior to doing something dangerous like browsing
the web or reading mail. 

On the other hand, one could always inject some form of malware into the
unpriviliged user's session which waits for the user to make use of RunAs, then
captures the password as it's typed or attacks the subsequently started process.
I guess the fun never ends...

--
Phil



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ