VL-Tone
@mc.videotr
| reply to jDyno
Re: Widget Security
For a widget to use any possibly harmful commands (system or local file access), it has to include some special -keys- in it's info.plist. So in theory, Safari would first warn you, then Dashboard would warn you when you try to run it the first time, that makes two warnings, which I think is enough. This is... in theory...
But...
Here is the problem, according to Apple's own documentation at:
»developer.apple.com/documentatio···n_1.html
"If any of these -keys- are present in your information property list file and it’s located outside of /Library/Widgets/, a dialog is presented to users upon your widget’s first load."
So in other words the warnings only appear if you run a Widget from outside the Library/Widget(s) folder.
Please note that widgets do not run automatically in any case, a newly installed widget must be dragged out of the widget bar first.
Actually the supposed "exploit" didn't even work for me as advertised, the "evil" widgets didn't appear in my widget bar, I had to manually double-click them in the Finder. Also note that Apple's standard widgets are installed in the root /Library/Widgets folder while Safari install them in the user ~/Library/Widgets folder.
I hope Apple will "fix" this, but in the mean time: Don't Panic |
|
jDyno
Premium
join:2001-02-20
Washington, DC
clubs:
| reply to jtanner
Yep, and just think how annoying all the "na-na-na-na-nas" from Windows users will be.
C'mon, Apple! Hook us (and your reputation!) up with an update that at least applies a bit of a salve for this!
--
Smart Marketing |
|
jtanner
To Add Speed, Add Lightness
Premium
join:2003-01-14
Cumming, GA
| reply to rjackson
said by rjackson  :The most a widget could do without an admin password for sudo is wipe out your home directory, since it runs under your UID. Better check again: the contents of /Applications, /Library, and /Users can be altered or wiped out without any user prompting, at the very least.
This is absolutely as big a disaster as ActiveX, especially since a website can cause Safari to install a widget. If Apple doesn't fix both of these issues, it spells the end of the legendary Mac "invincibility", and we'll all have to begin the monthly tithe to Symantec...
Jim |
|
bobbyzee
join:2001-02-15
Australia
| reply to rjackson
said by rjackson :The most a widget could do without an admin password for sudo is wipe out your home directory, since it runs under your UID. It's not that simple. Let's take the exploit with isync. Although fixed in Tiger, Dashboard could allow you to exploit this in a very user friendly way. Someone could author a widget that, for arguments sake, is some cool looking clock. You put some time delay feature in there so when it's, for example, August 31st at 11am it activates code which gains root through the isync exploit and from there, well, it's up to the hackers imagination. |
|
shavano
Even in America -- I long for America
join:2003-06-08
Dallas, TX
| reply to rjackson
said by rjackson :The most a widget could do without an admin password for sudo is wipe out your home directory, since it runs under your UID. The most? Like that's not enough?
Even with daily backups, you probably would lose something. Like that priceless photo you just uploaded and deleted from the camera. This is making me rethink Dashboard AND backup strategy. (As in, "I need a backup strategy!"  )
Hmmmm....maybe an Automator action that does an incremental backup to separate disk, changing ownership before and after. Or is that just a folder action......sheesh, more stuff to go learn....;)
--
Seek truth, not validation of existing beliefs. |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| reply to rjackson
said by rjackson :said by bobrk :So it's sort of up to the Dashboard to do security duties? No, It's Up To You™. Some people might think it's unfair but you shouldn't trust a widget you downloaded any more than you would trust a shell script, Automator workflow, or AppleScript. The good news is it's fairly easy to audit a widget simply because they're scripts, rather than a binary that isn't very human-readable. Eek! That sounds like something you'd overhear in the Windows Help forum.
--
Bush/Cheney '04! - Scared Straight
"Patriotism is supporting your country all the time and your government when it deserves it." |
|
jDyno
Premium
join:2001-02-20
Washington, DC
clubs:
| reply to rjackson
said by rjackson :said by bobrk :So it's sort of up to the Dashboard to do security duties? No, It's Up To You™. Some people might think it's unfair but you shouldn't trust a widget you downloaded any more than you would trust a shell script, Automator workflow, or AppleScript. The good news is it's fairly easy to audit a widget simply because they're scripts, rather than a binary that isn't very human-readable. Tell that to my 60-year old mother, for whom I'll be updating her new iBook to Tiger in the coming weeks.
Hell, tell that to my 36-year old sister, who is a very computer-savvy graphic designer, but wouldn't know what the code meant if you forced her to read it like a EULA every time the widget launched!
It's just not practical, rjackson. Even for me, and I write webdev code for a living. It would be really easy to hide some nefarious stuff in benign-looking code. And tell me, have you opened every single Widget you downloaded before loading it and thoroughly examined every single line to make sure it doesn't do anything you don't expect? C'mon.
And at this point, I'm not even asking for anything too advanced from Dashboard or Automator. I just want even the barest programmatic protections against nefarious stuff, like explicitly telling me that an app requires System or Net access (the current warning is too vague and I even missed that it was asking for access to the SYSTEM, rather than just telling me I'm running something for the first time) and ALSO telling me in idiot terms, why I should care about this.
This isn't about protecting those that know better or can do things to protect themselves. Apple is getting more and more into an uneducated consumer space, and that's a good thing, so they need to do more to protect those that can't protect themselves.
--
Smart Marketing |
|
rjackson
Premium,Mod
join:2002-04-02
Ringgold, GA
clubs:
Host:
SMC Networks
Automotive
VOIP Tech Chat
ViaTalk
Teleblend
| reply to bobrk
said by bobrk :So it's sort of up to the Dashboard to do security duties? No, It's Up To You™. Some people might think it's unfair but you shouldn't trust a widget you downloaded any more than you would trust a shell script, Automator workflow, or AppleScript. The good news is it's fairly easy to audit a widget simply because they're scripts, rather than a binary that isn't very human-readable. |
|
bobrk
You kids get offa my lawn
Premium
join:2000-02-02
San Jose, CA | reply to rjackson
So it's sort of up to the Dashboard to do security duties?
--
bobrk |
|
rjackson
Premium,Mod
join:2002-04-02
Ringgold, GA
clubs:
Host:
SMC Networks
Automotive
VOIP Tech Chat
ViaTalk
Teleblend
1 edit | reply to sporkme
Yeah, widgets can be debugged/ran in Safari but they won't have their full capabilities. The widget object is specific to Dashboard and as such none of its methods or properties are valid in Safari, so they wouldn't work anyways. That includes widget.system() for executing system commands.
Testing if window.widget exists is just a matter of good programming practices, there's no reason to execute code if you know it's going to fail or produce unexpected results. |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| reply to rjackson
said by rjackson :The widget object is only available in Dashboard, it doesn't have any properties in Safari. In fact most widgets will test to see if they're in the Dashboard environment before doing anything with the widget object: if(window.widget) {
// do widget-only stuff here
} I'm confused here, as I thought you were able to debug/run widgets in Safari 2.x?
If I were a betting man, I'd say the first big Mac "trojan" will be a malicious widget. If they can be loaded in Safari, look out, then browsing becomes Active-X dangerous.
--
Bush/Cheney '04! - Scared Straight
"Patriotism is supporting your country all the time and your government when it deserves it." |
|
Nighttime
join:2001-11-30 | reply to rjackson
I guess a widget could be cooked up to check that file. |
|
bobrk
You kids get offa my lawn
Premium
join:2000-02-02
San Jose, CA | reply to rjackson
That's what I was thinking. |
|
rjackson
Premium,Mod
join:2002-04-02
Ringgold, GA
clubs: | reply to bobrk
The most a widget could do without an admin password for sudo is wipe out your home directory, since it runs under your UID. |
|
bobrk
You kids get offa my lawn
Premium
join:2000-02-02
San Jose, CA
 ·SONIC.NET
| reply to shavano
said by shavano :I was hoping they might only be able to execute informational commands, not execute any arbitrary command like "rm -Rf". Can an adminstrator do an rm -Rf anywhere? Seems to me I have to use sudo just to edit the /etc/hosts file.
--
bobrk |
|
rjackson
Premium,Mod
join:2002-04-02
Ringgold, GA
clubs:
Host:
SMC Networks
Automotive
VOIP Tech Chat
ViaTalk
Teleblend
2 edits | reply to shavano
said by shavano :I was hoping they might only be able to execute informational commands, not execute any arbitrary command like "rm -Rf". I'd like them to not be able to do anything that writes or modifies a file via Unix command. Maybe there's something down in the bowels that prevents it? If you're concerned about a widget accessing the system open it up by right-clicking (or cmd-clicking) on the widget and go to "Show package contents". Open up the widget's Info.plist and look for a key that says "AllowSystem" or "AllowFullAccess". Without either of these keys set to "Yes" the widget has no authority to run system commands.
Likewise the absence of the "AllowNetwork" key prevents the widget from using network resources.
said by shavano :But if not, and if they actuallly are just mini-browsers, then did this make Safari vulnerable as well? That is, the widget object with all it's power, is now available to any Javascript? Or is it "limited" to just widgets executing via the Widget Server? The widget object is only available in Dashboard, it doesn't have any properties in Safari. In fact most widgets will test to see if they're in the Dashboard environment before doing anything with the widget object:
if(window.widget) {
// do widget-only stuff here
} |
|
shavano
Even in America -- I long for America
join:2003-06-08
Dallas, TX
| reply to shavano
I was hoping they might only be able to execute informational commands, not execute any arbitrary command like "rm -Rf".
I'd like them to not be able to do anything that writes or modifies a file via Unix command.
Maybe there's something down in the bowels that prevents it?
But if not, and if they actuallly are just mini-browsers, then did this make Safari vulnerable as well? That is, the widget object with all it's power, is now available to any Javascript? Or is it "limited" to just widgets executing via the Widget Server?
--
Seek truth, not validation of existing beliefs. |
|
