full-disclosure - Mac OSX 10.4 Dashboard Authentication Hijacking Vulnerability

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: <1683814a0505190725360b2170@mail.gmail.com>
Date: Thu May 19 15:25:50 2005
From: deeper at gmail.com (Daniel)
Subject: Mac OSX 10.4 Dashboard Authentication Hijacking
	Vulnerability

But then isnt this an issue with Sudo's grace period (ie should it be
tied down to that terminal process calling it and not other ones?)

I understand the theoretical issue you present, but lets be honest,
its not a vulnerability because to exploit this would require a
serious amount of user interaction beforehand

The same can be said for Linux/Solaris, in fact any OS which uses
sudo. Hell i think Gnomes GDesklets also could be exploited this was
as well, and in the case of them you dont even need to be reminded
that the content is bad as firefox just downloads them onto the
machine anyway



On 5/19/05, Jonathan Zdziarski <jonathan@...learelephant.com> wrote:
> 
> 
> Ok im running 10.4.1, i have a piece of javascript which calls sudo,
> yet im asked for my password straight after the sudo call has been
> made, therefore it WILL not run automatically.In order for you to have
> this fully exploitable widget, you would need the user to 1st call
> sudo to perform and action and then have the widget piggyback onto
> that session, surely?
> 
> Right. If you call sudo for anything else on your system, the widget can
> hijack this because Apple's implementation of sudo comes default with a
> grace period.
> 
> 
> 
> 
> with 10.4.1, once any widget has been downloaded, the user is
> presented with a box warning of the danger. If they do not do
> anything, the download DOES not take place and there is no code stored
> on the system.
> 
> Actually they're not prompted to execute it. They're prompted to download
> it. The user has the option to either download and install, or not download
> at all. But even without auto-install, this is still an issue, as people are
> likely to run several widgets without any knowledge of a trojan. Like I said
> in an earlier reply, you have 5-10 widgets all running in the background,
> invisible to a user, and the nature of widgets themselves make them ideal
> targets for malware. They're small applications that don't fall under the
> same scrutiny as other applications.
> 
> 
> I'm all for people finding holes in operating systems and reporting
> them, but with a matter like this it seems that there is more
> theoretical exploitation than actual exploitation.
> Tell you what, write up a bad widget and send it to us and lets see if
> we can replicate it..
> 
> ps.. http://www.apple.com/support/security/
> 
> Just add this line to any existing widget's "show" code, or background code
> if it has any:
> 
> widget.system("sudo id >> /tmp/out", null);
> 
> Then at some point in the future, authenticate for something. The next time
> the widget code runs (which could be in the background depending on the
> widget, or next time you view the dashboard), you'll see root in that file.
> 
> This is not a hard concept to grasp.
> 
> 
> 
> that e-mail address works, ive sent in a few issues myself regarding
> 10.3 and had no problems so far
> 
> Thanks for the link.
>  
> Jonathan 
>