Shell script exploit

> As I understand things, the type/creator information is NOT stored
> in the resource fork, but instead is part of the metadata stored in
> the HFS
> file system

That's true, but just to be clear, when you use the Finder to
override the 'Open with', it puts that application in the file's
resource fork.

I think this is a kludge and they should just change the creator code.

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

On 7.3.2006, space aliens observed batesje saying:
>Keeping the resource fork was just Apple's way of bowing to the older
>Mac programmers who complained about the "extreme effort" that would
>be needed to port their pre OS X programs to the new environment.

I think you're mixing up a few concepts here. As far as I can remember,
Apple never considered moving away from (its current version of) HFS. It
even implemented functions which allow programmers to have resource
forks on file systems which don't natively allow for them.

You're probably talking about Cocoa/Carbon, which has not a whole lot to
do with resource forks.


>It's been over 5 years now since the big migration to OS X, let's drop
>the old baggage and move on.

You still haven't provided any reason for why you'd want to do that.
Specifically, what problems do resource forks cause for you?


>Come on now, all that is really needed is the file name extension -
>whether visible or not.

Maybe all *you* really need are file name extensions. Some people may
have more sophisticated setups.


>If you want it to open with another program, change it. It only takes
>a second.

The problem here is that most people don't want all files of a given
type to open in the same application. I want my own JPGs to open in
Photoshop, but I want other people's JPGs to open in Preview. I want
PDFs I've created to open in Adobe Reader (because they may contain
forms), but I want PDFs from others to open in Preview (because Preview
opens faster). I want some text files to open in BBEdit, others in
TextEdit, even others in SubEthaEdit. Some of my HTML files open in
BBEdit, others open in Safari, and some I want to open in iCab.

Even if you don't need this kind of functionality, you should accept
that a lot of people rely on it.


>Let the change rule until changed again. If the file name extension
>says .jpg, then some program that can open jpegs should open it. It
>shouldn't instead be opened by Terminal because the fne
>wasİoverriddenİby some hidden preference set by the disguised
>application.

That is an entirely different problem. Of course the user should be able
to see what application a file opens in before he opens it, and of
course nothing bad should happen if the user opens a file he thinks is a
JPG. Those are security issues. They can be solved without taking away
basic functions of Mac OS.

l

- --
"Anything you think may be held against you."
  -- Philip K. Dick

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

iQA/AwUBRA3YVM0zN2kKTjB0EQIKnwCfXFnPrHph/lm3cq5bGExVRUy81oAAoJHU
WGq0kYhdWkk7EvkSd4hhyDyI
=iFOc
-----END PGP SIGNATURE-----

--On March 7, 2006 11:07:31 PM -0800 Google Kreme <gkremegmail.com> wrote:

> Here's a prefect example, in fact. I use preview to view PDFs, and
> does 90% of the Mac universe. However, some pdfs REQUIRE Acrobat
> Reader. I want those PDFs to open in Reader and the rest to open in
> preview.

I have this all the time too. What I do is right-click the PDF, select Open
With and pick Acrobat Reader (or drag and drop if Reader is already open).
What I don't do is right-click, select Open With, select Other, turn on
Always Open With, browser to Acrobat Reader and click OK.

If you open the document in Acrobat Reader, do a Save Copy, the new PDF
will still open with whatever all your other PDF's are associated with.

--On March 7, 2006 11:07:31 PM -0800 barefootguruparadise.net.nz wrote:

> I think this is a kludge and they should just change the creator code.

Not all programs have a creator code, or supported type codes. Especially
programs ported from Unix.

Creator codes have to be centralized across all machines, or they fail.
Which means you have to either have someone assigning the creator codes, or
hope there are no collisions.

Creator and type codes are invisible. What is to stop someone from
associating a file with a .JPG with the terminal.app using a creator/type
instead of the path as the current exploit does?

Treat the path to the application as a lengthy creator code and how is this
different from an OS using creator codes?

On or about 3/7/06 11:07 PM, thus spake "Google Kreme" <gkremegmail.com>:

> On 06 Mar 2006, at 11:30 , Joseph E. Bates wrote:
>> Come on now, all that is really needed is the file name extension -
>> whether visible or not. If you want it to open with another
>> program, change it. It only takes a second. Let the change rule
>> until changed again.
>
> This makes sense if you only have ONE application you want to open a
> particular extension with. This is not the case for many of us.
>
> Here's a prefect example, in fact. I use preview to view PDFs, and
> does 90% of the Mac universe. However, some pdfs REQUIRE Acrobat
> Reader. I want those PDFs to open in Reader and the rest to open in
> preview.
>
> And this has nothing to do with resource forks.

(1) Right now, it *does* have to do with resource forks, because (as my
article demonstrated) when you use Open With in the Finder's Get Info
dialog, the resource fork is exactly where your setting is stored. That's
how the exploit works. forsooth.

(2) How quickly, O people, we forget. Back in Mac OS 9 and before, unless
you were some kind of power user, you couldn't set the "Open With" of an
individual file at all. The only way to say "open this document with this
application" was to do it on a one-time basis, using the Open dialog from
within an app, or by dropping the document's icon on the application's. And
oh how we suffered - NOT! It wouldn't hurt us to return to that way of doing
things, and I'd be glad to do it that way if it helped with security. m.

--
matt neuburg, phd = matttidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
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/

On 2/23/06 15:29, "Nik" <gerberinik.net> wrote:

> I immediately worried about whether this would affect OmniWeb, since
> it uses much of the same code as Safari, but I was glad to see it
> didn't. OmniWeb makes a very sensible change to the "safe files"
> protocol, by instead letting the user define safe applications. Any
> files downloaded which are opened by those apps are automatically
> opened.

That is a false sense of security. Terminal is a "safe" application until it
runs a dangerous file. The idea that there are "safe" or "unsafe"
applications is a false one.

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

At 11:07 PM -0800 3/7/06, Google Kreme wrote:
>Here's a prefect example, in fact. I use preview to view PDFs, and
>does 90% of the Mac universe. However, some pdfs REQUIRE Acrobat
>Reader. I want those PDFs to open in Reader and the rest to open in

Acrobat uses type/creator ('PDF '/'CARO'), and you can create a
simple AppleScript to change the type/creator to Acrobat's. I do
this using the Big Cat Scripts contextual menu item plugin:
<http://ranchero.com/bigcat/>. I also have one that does the
opposite; set the type/creator to nulls, which reverts back to the
default application. I used this a lot with PDF files downloaded by
Firefox, which I really want to open in Preview.

--
Larry Rosenstein
lrosensteincatsincharge.com

On 3/9/06 21:02, "Kevin van Haaren" <kevinvanhaaren.net> wrote:

>> Here's a prefect example, in fact. I use preview to view PDFs, and
>> does 90% of the Mac universe. However, some pdfs REQUIRE Acrobat
>> Reader. I want those PDFs to open in Reader and the rest to open in
>> preview.
>
> I have this all the time too. What I do is right-click the PDF, select Open
> With and pick Acrobat Reader (or drag and drop if Reader is already open).
> What I don't do is right-click, select Open With, select Other, turn on
> Always Open With, browser to Acrobat Reader and click OK.

And if you don't have 35 applications that can open a PDF, that's still not
as convenient, nor any safer than saying "Acrobat opens THIS one and preview
opens everything else"

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

On 3/9/06 21:02, "Matt Neuburg" <matttidbits.com> wrote:

> (2) How quickly, O people, we forget. Back in Mac OS 9 and before, unless
> you were some kind of power user, you couldn't set the "Open With" of an
> individual file at all. The only way to say "open this document with this
> application" was to do it on a one-time basis, using the Open dialog from
> within an app, or by dropping the document's icon on the application's. And
> oh how we suffered - NOT! It wouldn't hurt us to return to that way of doing
> things, and I'd be glad to do it that way if it helped with security. m.

It doesn't help security at all, nor have I seen any sign that it would do
so beyond the idea that "less flexibility=more secure" which is completely
inaccurate.


[OK, folks, I think it's time to wind this thread down... I think we're going in circles. -Adam]


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

On 3/9/06 10:02 PM, "Matt Neuburg" <matttidbits.com> wrote:

> (2) How quickly, O people, we forget. Back in Mac OS 9 and before, unless
> you were some kind of power user, you couldn't set the "Open With" of an
> individual file at all. The only way to say "open this document with this
> application" was to do it on a one-time basis, using the Open dialog from
> within an app, or by dropping the document's icon on the application's. And
> oh how we suffered - NOT! It wouldn't hurt us to return to that way of doing
> things, and I'd be glad to do it that way if it helped with security. m.

But files saved using program X would open in program X when double-clicked
thanks to the creator code being set. It seems people today are saying that
a JPEG should open in Preview, if that's the default, regardless of what
program created it. That's not going back to ye olden days, that's
Windowsifying the OS.

I'm sure they weren't used by the majority but it wasn't *that* uncommon for
people to use either manual type/creator code editing or utilities that
could change them using drag n' drop methods.

On 09 Mar 2006, at 20:02 , Matt Neuburg wrote:
> Back in Mac OS 9 and before, unless
> you were some kind of power user, you couldn't set the "Open With"
> of an
> individual file at all.

Erm... that's not true. Html files for BBEdit opened in BBEdit.
htmls files I downloaded open in IE. It all just worked. I had an
entire directory of .tiff files on OS 8 that opened in Photoshop,
while the rest of the .tiff files opened in Graphic Converter. Most
jpegs opened in IE, but some opened in Graphic Converter. etc.

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

On 10.3.2006, space aliens observed Matt Neuburg saying:
>> And this has nothing to do with resource forks.
>(1) Right now, it *does* have to do with resource forks, because (as
>my article demonstrated) when you use Open With in the Finder's Get
>Info dialog, the resource fork is exactly where your setting is
>stored. That's how the exploit works. forsooth.

It does not matter where this particular piece of metadata is stored.
All that matters for this attack is that it isn't lost when the file is
moved - and that's the case for just about any piece of metadata, no
matter where it's stored.

The fact that Safari opens this file automatically is a bug in the
system's code, not a problem of how metadata is stored, and it could
have happened just as easily with creator codes.


>It wouldn't hurt us to return to that way of doing things, and I'd be
>glad to do it that way if it helped with security.

But it wouldn't. There's really no need to give up useful new features
because of a bug in how the system determines which files are save to
open. It simply makes no sense.

lucas

- --
I remember someone telling me "I have a better grip on reality than anyone else in the world."
"Then you must be lonely." I said. "You would do well to loosen your hold."
  -- Charlotte

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

iQA/AwUBRBHJGs0zN2kKTjB0EQLLhQCaA66tqEBFbqX2SEnxXs22F9wiDBIAoPc0
gh6yNiz9PKCLfK/JVSGR5GKe
=1gCK
-----END PGP SIGNATURE-----

On 3/10/06 16:24, "Nik" <gerberinik.net> wrote:

> Any application which cannot run code which might affect other files is a
> "safe" application. The number of programs which can be set up to
> automatically run programmatic code or macros is fairly small (albeit
> growing). I would never be afraid to open a file in Preview,
> OmniGraffle/Outliner, Mail, iPhoto, etc... These programs are incapable of
> doing more than reading and writing the one file they're working on, and
> cannot do damage to my computer.

And of course, you've reviewed the source code, and verified the safety of
every function in them. Because you know, the fact that all of those
applications are scriptable, and can, you know like, RUN APPLESCRIPTS leaves
no chance for danger ;-)

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

--On March 10, 2006 2:24:24 PM -0800 Nik <gerberinik.net> wrote:
> Any application which cannot run code which might affect other files is a
> "safe" application.

Not necessarily true. Buffer overflow exploits work by sending so much
data to a program that the program crashes, part of the data stream sent
might be executable code which is then accidentally run by the computer.
The "safe" program can be a vector for the attack if if improperly handles
the data overflow. THe amount of data required to do this can be quite
small depending on the application.

At 2:24 PM -0800 2006/03/10, Nik wrote:
>On Mar 9, 2006, at 8:02 PM, John C. Welch wrote:
>
>>On 2/23/06 15:29, "Nik" <<mailto:gerberinik.net>gerberinik.net> wrote:
>>
>>
>>>OmniWeb makes a very sensible change to the "safe files"
>>>
>>>protocol, by instead letting the user define safe applications. Any
>>>
>>>files downloaded which are opened by those apps are automatically
>>>
>>>opened.
>>>
>>
>>That is a false sense of security. Terminal is a "safe" application until it
>>
>>runs a dangerous file. The idea that there are "safe" or "unsafe"
>>
>>applications is a false one.
>>
>
>While I agree that a user should never assume that a program is
>definitely secure, I respectfully disagree with your conclusion that
>no program can be considered safe.
>
>Any application which cannot run code which might affect other files
>is a "safe" application. The number of programs which can be set up
>to automatically run programmatic code or macros is fairly small
>(albeit growing). I would never be afraid to open a file in Preview,
>OmniGraffle/Outliner, Mail, iPhoto, etc... These programs are
>incapable of doing more than reading and writing the one file
>they're working on, and cannot do damage to my computer.

        Preview leverages Apple's PostScript interpreter for PDFs,
and PostScript is a programming language. There have been PostScript
attacks, to jumble words or scramble printers. I don't know how
constrained ("sandboxed") the language is, though.

>For that matter, even a program like Photoshop, which supports
>actions and macros, cannot be induced to run them automatically
>without explicit user instructions (droplets excepted, but those are
>applications, not documents). The same is true of powerful and
>programmable text editors like TextMate or BBEdit.

        Well, BBEdit can run scripts, and supports shell worksheets.
I don't think there's a bug that would automatically execute a shell
worksheet, but betting on the correctness and safety of BBEdit is not
good security.

>The only programs which really come to mind that could be dangerous
>are terminal programs, many remote access programs/FTP utilities
>(mostly because they could be a vector for duplication of files),
>the Microsoft Office suite (ahhh, VB Macros! Will they never
>learn?), and Dashboard. I'm sure there are others, but the programs
>which can just fire off arbitrary and potentially dangerous code are
>few and far between.

        There are certainly safe programs (TextEdit is probably one,
and Stickies another). Making a judgement about *exactly which are
safe* is a good way to find your mistakes, when someone exploits them.

        What if someone added a new file format to Graphic Converter
next week, and it could be compromised? Macs configured to trust GC
today because it's (presumably) safe now would then be vulnerable.


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

On Mar 9, 2006, kevinv wrote:

>What I do is right-click the PDF, select Open
>With and pick Acrobat Reader (or drag and drop if Reader is already open).
>What I don't do is right-click, select Open With, select Other, turn on
>Always Open With, browser to Acrobat Reader and click OK.

If you're happy with using your wetware to remember which PDF is
which, good for you. I write for the people who would rather have
the computer do the remembering. Taking that capability away won't
solve the security problem (as others have pointed out), but it will
significantly degrade the productivity we have gained with OS X.
Computers in general, and Macs in particular, should give users the
flexibility to avoid "one size fits all" situations, which never fit
all people well (though they may fit everyone equally badly).

Carl

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

On 11.3.2006, space aliens observed Nik saying:
>(...) These programs are incapable of doing more than reading and
>writing the one file they're working on, and cannot do damage to my
>computer.

It should be noted that any application could potentially do damage to
your computer. A common problem are buffer overflows, which may lead to
applications running arbitrary code stored inside a file. In fact, there
was just such a buffer overflow in QuickTime a few months ago, which
means that *all* applications using QT to read image files are
vulnerable if their host OS is running a vulnerable version of
QuickTime.

Buffer overflows are the most common reason for security holes. There
are several ways to protect against buffer overflows (such as using
sensible/modern/high-level programming languages, or executable space
protection). This does not change the main point: Any application and
any file is potentially unsave. The OS can never provide total security.
Do not rely on the OS for your protection. Do not open suspicious files.
Do not click on links in suspicious e-mails.

lucas

- --
"There is no more noble occupation in the world than to assist another human being - to help someone succeed."
  -- Alan Loy McGinnis

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

iQA/AwUBRBMr180zN2kKTjB0EQL83QCgjDfhlIjM2wvnxBOBuHKvavdOKxMAoLAr
SVxGb/BysUKkKd7XFDLCgoa+
=JJ+a
-----END PGP SIGNATURE-----

On Mar 13, 2006, at 9:49 AM, Chris Pepper wrote:

> What if someone added a new file format to Graphic Converter
> next week, and it could be compromised? Macs configured to trust GC
> today because it's (presumably) safe now would then be vulnerable.

Or finds yet another JPEG decoding exploit which GC happens to fall
victim to. (That would imply that GC uses an outside library for
JPEG work--I don't know whether it does--since while GC is a fine
program and heavily used by a small expert subset of Mac users, it's
hardly a likely target, as there are so few instances of it.)

Or PNG, or any other the other formats it knows.

Right now, to change the subject, it appears that iTunes on Mac and
Windows is unsafe.

   --John

On 3/13/06 12:49 PM, "Kevin van Haaren" <kevinvanhaaren.net> wrote:

> --On March 10, 2006 2:24:24 PM -0800 Nik <gerberinik.net> wrote:
>> Any application which cannot run code which might affect other files is a
>> "safe" application.
>
> Not necessarily true. Buffer overflow exploits work by sending so much
> data to a program that the program crashes, part of the data stream sent
> might be executable code which is then accidentally run by the computer.
> The "safe" program can be a vector for the attack if if improperly handles
> the data overflow. THe amount of data required to do this can be quite
> small depending on the application.

Buffer overflows are outside the scope of the problem we're discussing, that
is, unknowingly executing code either by files being auto-opened/run by an
application (Safari, Mail, etc.) or by double-clicking. A buffer overflow
exploit would work even if you used the Open dialog from within the
appropriate application.


[And again, let's wind this thread down... -Adam]