full-disclosure - IE is just as safe as FireFox

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]

Message-ID: <008601c4d2db$5a5ef5a0$0501a8c0@andromeda>
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