'Evil' Widgets in Dashboard

Apples says[1] the just released Mac OS X 10.4.2 protects against an aspect
of Dashboard's poor security model. As we know, an 'evil Widget' can ID
itself as an Apple provided Widget. When installed in ~/Library/Widgets it
will override Apple's Widget but appear to the user as Apple's Widget. (Yes,
the user will have to somewhat consciously download and install such a
Widget.)

The protection consists of a dialog warning the user.

My impression is that this is as lame as the warning message you get when you
have the system launch an app for the first time. (Apple's 'fix' for the URL
scheme security hole[2]). It only helps the very few users who are actually
aware of the risk in the first place. I've seen 'normal people' respond to it
without any comprehension at all of what it means to warn against. They just
click "OK". It seems to me that that shows that this sort of 'fix' is
self-defeating. Users will only get more used to "just having to OK annoying
warning messages"....

Is fixing security holes by displaying dialogs, which users must *understand*
in order to be able to make the right choice, a good idea?

Is this a new trend? Or has Apple always done fixes like this and I'm only
now aware of them?


Btw, yes, I realize that someone might *want* to run a Widget that replaces
an Apple-provided one. I think you could deal with that by offering a Widgets
Prefernces Pane where users can en-/disable Widgets, including Apple-provided
ones. With that in place, you could then have Dashboard not allow local
Widgets to override systemwide ones simply by being installed, yet still
allow users to replace Apple-provided Widgets if they choose to.

Similarly, it seems to me the URL scheme security hole could be fixed by
never having the system pass on requests to open a file to applications that
have never been launched. The user should have at least launched the app 1
time - *that* should be the first moment LaunchServices allows an app to
register what URL schemes and file types it can handle.

Or am I overlooking something and are these holess truly impossible to plug?


[1] <http://docs.info.apple.com/article.html?artnum=301948>

[2] <http://www.euronet.nl/~tekelenb/playground/security/URLschemes/>


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

>From: Sander Tekelenburg <tekelenbeuronet.nl>

>Apples says[1] the just released Mac OS X 10.4.2 protects against an aspect
>of Dashboard's poor security model. As we know, an 'evil Widget' can ID
>itself as an Apple provided Widget. When installed in ~/Library/Widgets it
>will override Apple's Widget but appear to the user as Apple's Widget.
>(Yes,
>the user will have to somewhat consciously download and install such a
>Widget.)

Is the moral of the story that if one is not a Computer Engineer, one should
steer away from importing non-Apple widgets? Just how much of a danger are
these evil widgets... or are they just a sign of nasty things to come?

Paul

At 11:59 AM 07/14/2005 -0700, Sander Tekelenburg wrote:
>Is fixing security holes by displaying dialogs, which users must *understand*
>in order to be able to make the right choice, a good idea?

Well put. It's not a new problem or observation by any means, but this is
well stated.

>Is this a new trend? Or has Apple always done fixes like this and I'm only
>now aware of them?

It seems to me that Apple used to be better. However, this is an
industry-wide problem, and it goes far beyond just security. In general,
asking the user to make a technical decision, unrelated to the user's
expertise or reason for interaction with the computer, lies somewhere
between very weak and totally useless.

>Or am I overlooking something and are these holes truly impossible to plug?

In general, security works well only when it is designed in from the start.
The second best is when it's had the chance to go through many iterations
(eg Unix). This looks like a case where security wasn't taken seriously in
the design, and that makes it difficult to fix effectively. Good bandages
are probably the best we can hope for.

Edward
Art Works by Melynda Reid: http://paleo.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16.7.2005, space aliens observed patrosh saying:
>Is the moral of the story that if one is not a Computer Engineer, one
>should steer away from importing non-Apple widgets?

Not any more than you should stay away from non-Apple applications.
Widgets aren't a security risk per se. The problem is that there were
ways for web sites to install widgets into your system without your
knowledge.

Personally, I don't think that Apple has become worse as far as security
is concerned. The problem is that the world has become more complicated.
We have always-on Internet connections. The OS has a lot more features
which can potentially contain security problems. There are more
applications using the Internet.

Of course, Apple could and should become better, but I don't think
they've become worse in the recent years.

I would like to make one last point about the URL scheme security hole.
Sander's solution sounds nice, but if Apple had done it this way,
launching documents by double-clicking on them wouldn't have worked
until the user had run the application at least once, either. And then
there are the helper applications which you can't run manually. I think
Apple's solution is fairly elegant, and since the user will see this
particular dialog box very rarely, it's unlikely that he'll develop a
"just hit return"-attitude.

lucas

- --
"Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed."
  -- Eisenhower

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2

iQA/AwUBQtjVws0zN2kKTjB0EQJ5ggCffQl0Svxj+ml/46sVnW1Wp+PBhx4AoKFg
DruSA6a3RBfCQfaoPODB5yHg
=9A7o
-----END PGP SIGNATURE-----

At 22:42 -0700 UTC, on 2005/07/15, Paul Atroshenko wrote:

[...]

> Is the moral of the story that if one is not a Computer Engineer, one should
> steer away from importing non-Apple widgets? Just how much of a danger are
> these evil widgets... or are they just a sign of nasty things to come?

Personally I think that at this moment the greatest risk seems to be in
social engineering. Because 'it is just a Widget' people will be less careful
than with installing applications - while in reality Widgets can do as much
harm (be it on purpose or by accident). Possibly we should add to that that
Widgets are probably the easiest type of GUI app that can be created. So it
seems likely to be an interesting attack vector for someone who knows how to
do some 'bad' cli things but is not an experience Mac programmer. If you know
a little HTML/CSS/javascript, you can just grab an existing Widget, change it
and redistribute it.

This is especially important because Apple itself considered Widgets a risk.
The Dashboard documentation explains that Widgets must declare what level of
access they want, and it *used to say* "If your widget is working with
resources that pose a security threat to the user, the user must approve
before access is granted.". However, within days after it became public that
10.4.0's Safari would happily install third-party Widgets that could do
anything without requiring any user authentication, Apple silently erased
that sentence from its online documentation.

So today the documentation says Widgets need to declare what level of access
they want. But in practice that means thet Widgets then automagically *gets*
the level of access it requests - the user isn't asked anything.

Note that the argument that Widgets cannot do any special harm (compared to
'normal' aplications) isn't that interesting. What is interesting is that
Apple itself considered this a danger, designed a security model for it,
documented that publicly and when it turned out (within days) that Apple had
only written that documentarion, but *not implemented* it, Apple simply
changed the specs to reflect reality. I think this ought to scare the shit
out of Mac users. What other security risks is Apple, or will Apple be,
treating this way?

I wrote all this up at
<http://www.euronet.nl/~tekelenb/playground/security/Dashboard/>, if you want
more details and/or pointers to sources.


Note that my message just used 10.4.2 Widget 'safety improvement' to discuss
something bigger: what constitutes a "securtity fix"? (I suggested to Adam
that perhaps this ought to be a new thread, to indicate more clearly that
this is not about Widgets - just takes it as an example to touch upon
something much bigger).


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 7/14/05 13:59, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

> Similarly, it seems to me the URL scheme security hole could be fixed by
> never having the system pass on requests to open a file to applications that
> have never been launched. The user should have at least launched the app 1
> time - *that* should be the first moment LaunchServices allows an app to
> register what URL schemes and file types it can handle.

That would completely break Launch Services, and make the system far harder
to use. You'd have to manually open every application you'd ever want to
use, (effectively everything in /Applications to be sure) and quit it before
you ever did anything, since if you didn't, double-clicking on a document
file would cease to function.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 7/19/05 10:49, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

>> Is the moral of the story that if one is not a Computer Engineer, one should
>> steer away from importing non-Apple widgets? Just how much of a danger are
>> these evil widgets... or are they just a sign of nasty things to come?
>
> Personally I think that at this moment the greatest risk seems to be in
> social engineering. Because 'it is just a Widget' people will be less careful
> than with installing applications - while in reality Widgets can do as much
> harm (be it on purpose or by accident). Possibly we should add to that that
> Widgets are probably the easiest type of GUI app that can be created. So it
> seems likely to be an interesting attack vector for someone who knows how to
> do some 'bad' cli things but is not an experience Mac programmer. If you know
> a little HTML/CSS/javascript, you can just grab an existing Widget, change it
> and redistribute it.

This is where Mac users' inexperience with malware, and how to avoid it
will, unfortunately, bite them. Code is code. There's no such thing as
inherently 'safe' code just as there's no such thing as inherently 'unsafe'
code. But once you run it, you're at the mercy of the code. This assumption
of "I have a Mac, so I'm safe" needs to be purged from the Mac User
collective consciousness, and the sooner the better.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 09:26 -0700 UTC, on 2005/07/19, John C. Welch wrote:

> On 7/14/05 13:59, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:
>
>> Similarly, it seems to me the URL scheme security hole could be fixed by
>> never having the system pass on requests to open a file to applications that
>> have never been launched. The user should have at least launched the app 1
>> time - *that* should be the first moment LaunchServices allows an app to
>> register what URL schemes and file types it can handle.
>
> That would completely break Launch Services

Well, only in the sense that while right now Launch Services registers apps
as soon as their copntainer has been visible in the Finder once, you'd then
have to manually launch an app once. I'm only talking about how
LaunchServices registers new apps. Once registered, it would work just like
it does now.

But yeah, I realise this approach would negatively affect convenience.
Perhaps too much so. Security and conceniency have never liked each other
much...

Anyway, I didn't mean to imply I know of a far better fix than what Apple
did. I just think Apple's fix is a bit of a lame hack and felt that when I
say that, I should at least /try/ to think of how it could be done better :)
(Thus I am much more interested in what *would* be a good fix than in how my
suggestion is not one.)

> , and make the system far harder
> to use. You'd have to manually open every application you'd ever want to
> use, (effectively everything in /Applications to be sure)

LaunchServices could use a pre-defined white-list for all the apps that you
automatically get with the OS install.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 7/19/05 12:02, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

>> , and make the system far harder
>> to use. You'd have to manually open every application you'd ever want to
>> use, (effectively everything in /Applications to be sure)
>
> LaunchServices could use a pre-defined white-list for all the apps that you
> automatically get with the OS install.

Which then protects you how? Not all malware needs to do the dirty work on
its own. For example, I can do quite a few evil things with Internet
Connect, or iChat?

There's no easy answer, but I think that Apple's notification mechanism ends
up being the only one that doesn't get progressively more complicated.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On or about 7/19/05 9:26 AM, thus spake "John C. Welch" <jwelchbynkii.com>:

> On 7/19/05 10:49, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:
>
>>> Is the moral of the story that if one is not a Computer Engineer, one should
>>> steer away from importing non-Apple widgets? Just how much of a danger are
>>> these evil widgets... or are they just a sign of nasty things to come?
>>
>> Personally I think that at this moment the greatest risk seems to be in
>> social engineering. Because 'it is just a Widget' people will be less careful
>> than with installing applications - while in reality Widgets can do as much
>> harm (be it on purpose or by accident).
>
> This is where Mac users' inexperience with malware, and how to avoid it
> will, unfortunately, bite them. Code is code. There's no such thing as
> inherently 'safe' code just as there's no such thing as inherently 'unsafe'
> code

I agree - my initial reaction to this thread was that this has nothing to do
with Dashboard widgets. The danger is the Internet: download an application
and run it, and kaboom! It could do anything.

But it is not true that Widgets can do just as much harm, since a Widget is
by default confined to a tight little world where it can't touch the files
on your hard disk. To touch those files, a widget must "declare its
intentions". You can know in advance the security level it will attempt to
gain.

<http://developer.apple.com/documentation/AppleApplications/Conceptual/Dashb
oard_Tutorial/index.html>

An application, on the other hand, is confined only by Unix permissions,
which is a far weaker restriction. So in reality an application is
potentially far more harmful.

For this reason I regard the whole Widget scare as a red herring. Personally
I'm much more worried about *accidental* bad programming. Widgets are a
magnet for "script kiddies" who don't understand memory and resource
management. I don't use any Widgets - not Apple's, not anyone's. m.

--
matt neuburg, phd = matttidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide -
http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/

> That would completely break Launch Services, and make the system far harder
> to use. You'd have to manually open every application you'd ever want to
> use, (effectively everything in /Applications to be sure) and quit it before
> you ever did anything, since if you didn't, double-clicking on a document
> file would cease to function.
 
And what you'd find, I'm sure, is that common (but bad!) advice for people would be to select everything in the Applications Folder and open it, then quit everything (or restart) when they are all open (a killer for memory, but since you wouldn't be using anything, not a big deal). I'm sure helpful people would even come up with applescripts to do this for you (perhaps one you to attach to the folder that just does this for any new items in it).
 
=Tony.Meyer

>> Personally I think that at this moment the greatest risk seems to be in
>> social engineering.
[...]
> This is where Mac users' inexperience with malware, and how to avoid it
> will, unfortunately, bite them. Code is code. There's no such thing as
> inherently 'safe' code just as there's no such thing as inherently 'unsafe'
> code. [...] This assumption of "I have a Mac, so I'm safe" needs to be
> purged from the Mac User collective consciousness, and the sooner the
> better.
 
I wonder if we are maybe reaching limits in how much a system can help protect the user (without significant loss of (possibly new) functionality). User education really is the way in which the biggest difference can be made in security.
 
I think perhaps part of it is just that there have been so many changes recently (as mentioned elsewhere in this thread) - the always-on Internet connection, and so on, and people just haven't caught up. People (even non-technical ones) did seem to grasp the virus-on-a-floppy concept, so I'm sure they can grasp these new issues, too - we (and Apple & Microsoft could help a lot here) just have to put in the education effort (don't type your password without thinking about why you are, do use a limited access account day-to-day, and so on).
 
(On the other hand, maybe virus-on-a-floppy is easier to comprehend, since if you share (eg) chapstick, you can catch diseases, so it's easy to relate that to computer disease. A malicious user somewhere gaining access through an open port is maybe harder to relate to 'normal' life).
 
=Tony.Meyer

On Jul 19, 2005, John C. Welch wrote:

>On 7/14/05 13:59, "Sander Tekelenburg" <tekelenb euronet.nl> wrote:
>> Similarly, it seems to me the URL scheme security hole could be fixed by
>> never having the system pass on requests to open a file to applications that
>> have never been launched. The user should have at least launched the app 1
>> time - *that* should be the first moment LaunchServices allows an app to
>> register what URL schemes and file types it can handle.
>
>That would completely break Launch Services, and make the system far harder
>to use. You'd have to manually open every application you'd ever want to
>use, (effectively everything in /Applications to be sure) and quit it before
>you ever did anything, since if you didn't, double-clicking on a document
>file would cease to function.

C'mon, how often is anyone going to have a document which expects to
be opened by an application that they have NEVER tried to use before?

Besides, there is an intelligent compromise: When the OS is
installed, it could add to a security log every app and widget which
was included as "already opened once". (You don't want to put the
mark on the app itself, since a new app could thereby smuggle a false
mark onto your system.) Similarly, Apple's Software Update could log
(or re-log) every app and widget that it knows about as "already
opened". Then the only apps which would not auto-start from a
double-clicked document would be those which came from other sources,
and that's precisely the ones that should be handled extra carefully.

--
Carl Scott Zimmerman, CCP
. iname: http://public.xdi.org/=Carl.Scott.Zimmerman
Certified Computing Professional (ICCP) Campanologist
Voicemail: +1-314-821-8437 E-mail: csz_stlswbell.net

--On 7/21/05 3:29 PM -0700 Carl S. Zimmerman wrote:

> C'mon, how often is anyone going to have a document which expects to be
> opened by an application that they have NEVER tried to use before?

Every time you upgrade an application whose documents you work with.


Dave

At 3:29 PM -0700 2005/07/21, Carl S. Zimmerman wrote:
>On Jul 19, 2005, John C. Welch wrote:
>
>>On 7/14/05 13:59, "Sander Tekelenburg" <tekelenb euronet.nl> wrote:
>>> Similarly, it seems to me the URL scheme security hole could be fixed by
>>> never having the system pass on requests to open a file to
>>>applications that
>>> have never been launched. The user should have at least launched the app 1
>>> time - *that* should be the first moment LaunchServices allows an app to
>>> register what URL schemes and file types it can handle.
>>
>>That would completely break Launch Services, and make the system far harder
>>to use. You'd have to manually open every application you'd ever want to
>>use, (effectively everything in /Applications to be sure) and quit it before
>>you ever did anything, since if you didn't, double-clicking on a document
>>file would cease to function.
>
>C'mon, how often is anyone going to have a document which expects to
>be opened by an application that they have NEVER tried to use before?

        Exactly once per application per installation. If you
reinstall/upgrade once per year, and use 80 applications, call it 80
times per year.

        Having *nothing* happen the first time you use a Word
document would be a bit of a loss, and might be major for people who
don't know that Preview is what handles the .PDF file they just got,
or where to find Keychain Access to deal with the .crt or .cer file
just received.

        Note that if I put up SuperNifty.command for download, and it
contained "rm -f ~", it wouldn't be blocked by this (many people have
run Terminal at least once, even if just to check it out).

>Besides, there is an intelligent compromise: When the OS is
>installed, it could add to a security log every app and widget which
>was included as "already opened once". (You don't want to put the
>mark on the app itself, since a new app could thereby smuggle a false
>mark onto your system.) Similarly, Apple's Software Update could log
>(or re-log) every app and widget that it knows about as "already
>opened". Then the only apps which would not auto-start from a
>double-clicked document would be those which came from other sources,
>and that's precisely the ones that should be handled extra carefully.

        Note that this is basically how Apple's Keychain works. I
suspect they're registering exact paths and perhaps MD5 checksums (or
more likely trusting version numbers), as when you run a new version
of Safari, Eudora, or whatever and it wants to access the Keychain
the first time, it prompts you to update the allowance from the old
copy to the new one.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 19:41 -0400 2005/07/21, Dave Scocca wrote:
>--On 7/21/05 3:29 PM -0700 Carl S. Zimmerman wrote:
>>C'mon, how often is anyone going to have a document which expects to be
>>opened by an application that they have NEVER tried to use before?
>
>Every time you upgrade an application whose documents you work with.

OK, I'll concede that.


And 20:20 -0400 2005/07/21, Chris Pepper commented :
> Exactly once per application per installation. If you
>reinstall/upgrade once per year, and use 80 applications, call it 80
>times per year.
>
> Having *nothing* happen the first time you use a Word
>document would be a bit of a loss, and might be major for ...

Who ever suggested that Launch Services ought to do "nothing" if the
app hadn't run before? (Don't answer - that's a rhetorical question.)


For unregistered programs, Launch Services could warn, "The
application [insert name here] has never been run on this system.
Please confirm that its installation was authorized by the system
manager." For programs that have been updated since registration,
Launch Services could warn, "The application [insert name here] has
been modified since the last time it was run on this system. Please
confirm that the change was authorized by the system manager."

In both cases, if the app was from Apple, Software Upgrade could have
handled the situation as I suggested elsewhere in my message. But
for all programs, including those from Apple, the check for "modified
since last execution" would catch incidents of maliciously
modifications by malware, as well as inadvertent corruptions through
hardware error.

We want security that's managed by the OS, completely independent of
the apps and widgets and their producers. While such an enhancement
to Launch Services wouldn't be foolproof (fools are so darned
ingenious!), nor cover all security risks, it would be better than
what we have now, IMNHSO, and the dialog would be a small price to
pay for that added level of security. Of course there might be even
better ways of handling it than what I (and others) have suggested.

Carl

On 7/21/05 17:29, "Meyer, Tony" <T.A.Meyermassey.ac.nz> wrote:

>> That would completely break Launch Services, and make the system far harder
>> to use. You'd have to manually open every application you'd ever want to
>> use, (effectively everything in /Applications to be sure) and quit it before
>> you ever did anything, since if you didn't, double-clicking on a document
>> file would cease to function.
>
> And what you'd find, I'm sure, is that common (but bad!) advice for people
> would be to select everything in the Applications Folder and open it, then
> quit everything (or restart) when they are all open (a killer for memory, but
> since you wouldn't be using anything, not a big deal). I'm sure helpful
> people would even come up with applescripts to do this for you (perhaps one
> you to attach to the folder that just does this for any new items in it).

And at that point, you've completely bypassed the non-existent security
enhancement breaking Launch Services didn't give you.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 7/21/05 17:29, "Carl S. Zimmerman" <csz_stlswbell.net> wrote:
> Besides, there is an intelligent compromise: When the OS is
> installed, it could add to a security log every app and widget which
> was included as "already opened once". (You don't want to put the
> mark on the app itself, since a new app could thereby smuggle a false
> mark onto your system.) Similarly, Apple's Software Update could log
> (or re-log) every app and widget that it knows about as "already
> opened". Then the only apps which would not auto-start from a
> double-clicked document would be those which came from other sources,
> and that's precisely the ones that should be handled extra carefully.

Like what? Acrobat? Photoshop? And when you do a new OS install, that method
won't work. How are you going to open an application before an OS install?
If you're updating from a version that didn't support that, then you have no
way to do this either.

The current system works and breaks nothing.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 7/23/05 07:51, "Carl S. Zimmerman" <csz_stlswbell.net> wrote:

> For unregistered programs, Launch Services could warn, "The
> application [insert name here] has never been run on this system.
> Please confirm that its installation was authorized by the system
> manager."

That's the current behavior

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com