Not specifically because of the "piracy" of Mac OS X (and I'm not certain that it should actually be called "piracy" - even in the colloquial sense - to buy a copy of Mac OS X and install it on a non-Mac, even if the EULA is enforcable), but the TPM capability of the Intel chipset does make Open Source Darwin a problem. Releasing the source to the OS without making it possible to use the source to bypass any strong DRM Apple happened to have a use for just becomes harder and more expensive.
First, the "." chaarcter in a UNIX file name doesn't separate the name from the extension. It's just another character. UNIX applications have traditionally used the first or last few characters of the name for a variety of reasons, but that's just a convention and you find things like "s.file" or "file,v" or "file~" or "._file", as well as applications using 'magic numbers' in the first few characters of the file... like "#!" or "%!PS" or ": ".
And the UNIX shell didn't use filename extensions to determine the application to run files. The UNIX shell uses a verb-noun syntax, not the object-action syntax of modern GUIs. The application was explicitly named in the first word of the command.
The extended UNIX 'ls' command from BSD, the one that established the convention of using "*", "/", "@", and so on at the end of file names to indicate the file's metatdata, payed no attention to the name itself to determine how to display a file.
Many individual GUI file managers on UNIX have, but the majority of GUI file managers on UNIX are copied from Windows, one way or another. The ones that are older typically made "deeper" decisions... I've had mail folders with no extensions at all show up as a little 'in tray', based on the contents of the file.
Windows file extensions are based on the DOS 1.x "8 character name plus 3 character type", which was based on the CP/M 6+3 filename, which was based on the ISIS 6+3 filename, which was based on DEC's RT- and RSX- operating systems that used 6+3 filenames.
They started out as a genuine file type, like the Mac creator and type Finder Info, which is why they are considered "strong" type information rather than "weak" type information. It's a pity that the OS X Finder didn't follow the early UNIX precedent of considering all 'creator/content' meta-information as "weak", and using the file itself as the primary source... the way the UNIX commands "ls" and "file" do.
why the heck doesn't Safari or Mail notice that ( even just one file of ) the attachment has the execute bit set and sound the warning bell ?
That's the wrong question, because there's other ways to sneak a script past Safari using LaunchServices that don't involve having the execute bit set or any other indication that the document is a script, that don't involve Terminal or/bin/bash. I'm not going to go into details, but if you think about all the other scripting languages available on OS X you should be able to think of some approaches.
LaunchServices has been involved in two other exploits similar to this one in the past, and the changes that Apple made to "fix" them were superficial... this exploit is proof of that.
The right question is, why does Safari or Mail have to trust LaunchServices, when LaunchServices is by design not a safe way to open untrusted documents?
Nope, they try something different: They try to implement a zone model.
They also implement a Zone model, as well as using signed "safe" documents that may contain active content. Originally the "safe documents" model unconditionally overrode the zone model - signed documents were trusted in all zones. That enabled exploits piggybacking on trusted documents, so the zone model (which I agree is broken) now overrides the "safe documents" model.
Active X is somewhat similar to the safe application model.
Not in any sense. Active X components are documents in the "safe application" model, not applications. Safe applications are applications that are installed by the user or the system vendor and registered by the creator after explicit installation as providing a "sandboxed" environment in which unsafe documents can be examined. Any object received from an untrusted source is an "unsafe document" regardless of whether it contains active content or not.
I don't want to have a full blown rigorous mandatory access control (MAC)security model on my Mac.
Anything less creates a false sense of security.
The system should interact with most of the existing tools, should be easy to understand and should let the user [have] the last word.
The "safe applications" model satisfies all these requirements, AND over the past 10 years since Microsoft made 'drive-by execution' the norm it has proven itself time and time again.
I have more than 100 users that range from the naive to "top geeks". I have had people repeatedly come to me and say "um, Peter, I clicked on the wrong button again and I think I have a virus" same people, over and over again, because the zones-plus-trusted-documents model requires the user to routinely approve potentially dangerous actions... so they're trained to hit "yes", "open", "launch", "infect me", or whatever the interface-of-the-week pops up. I've never had someone come to me more than once and say "Peter, I downloaded a file, opened my downloads directory, and double clicked on the file, and now I'm infected". Not once, not even the people I have to walk through selecting a printer every week.
Most of the infections we got were from people reflexively approving an infection... despite the fact that most of the time IE (along with its related apps) was banned and only half a dozen *technical* people were allowed to use it.
The "safe documents" model requires all new tools, is complex and hard to understand, and - unless it's made grossly inconvenient by forcing the user to back out of partially completed actions and return to the Finder to explicitly change the state of applications - it will train the user to reflexively approve annoying dialog boxes.
Yep, dragging them or selecting the app using "open with" is definitely recommended, particularly for files you just downloaded. Not just for security, but also to avoid annoyances.
One thing I've found is that a lot of files in disk images or stuffit archives (by the by, stuffit archives ALSO maintain the dangerous metadata) have the "wrong" default application anyway. I use Camino as my browser, for example, and for a long time I used the PDF plugin for PDFs so Camino was my PDF viewer as well. Typically, HTML help files and PDF docs would open in Safari (or, in some cases, Internet Explorer!) and Preview if I didn't override them.
You can just add some more attributes to define exceptions and refine the scheme.
You can't fix this scheme, not without ending up with "safe" applications anyway.
No, I'm not adding more attributes, I'm describing what would be required if you actually implemented this scheme.
If I edit "/etc/rc" in "vi" then the next time the system comes up "/bin/bash" will open "/etc/rc" and go "/etc/rc was edited by vi, I'm not going to run" and you won't even be able to get into single-user mode.
If I edit the configuration file for Apache (shipped by Apple) with TextEdit (shipped by Apple) then Apache won't run.
This situation, where a program is created by one application and used by another is all over the place.
Now you have to have both "safe applications" (such as viewers) and "safe editors". So your scheme reduces to a "safe application" model, but one that is intrusive and provides a false sense of security, because...
Fair enough, my proposal won't stop such exploits in the first place....applying the "safe application" model from the browser absolutely prevents those exploits and any variation of those exploits from happening, and when a bug *is* found in a safe application it takes less than 15 minutes to fix it... without forcing the user to deal with the problem outside the browser.
Microsoft has been attempting to get the scheme you're proposing working since 1997, and they're only trying to do it for a *subset* of the domain you're talking about. When they implemented it in the first place they did such a bad job that they created the worst storm of viruses and email worms the net had ever seen. Over a couple of years the number of active exploits of Microsoft's trust model turned viruses from a minor problem that you could easily avoid by a few simple habits to the biggest problem on the net... I'm seeing gigabytes of just rejected viruses and worms a month.
The only way to make "trusted files" work is to go to mandatory access control, and the amount of inconvenience that imposes is insane.
Security must be as convenient as possible or the user will circumvent the security measures.
Which is why limiting untrusted documents to only trusted applications unless a human explicitly requests that the document be opened outside the sandbox is the only model that works for a large population of users. It's convenient, and effective.
It requires a minimal level of sophistication from the user, yes, but people are actually LESS likely to mistakenly tell the system to trust something they shouldn't than in the scheme you propose.
This would either be very inconvenient or it would need a very savvy user.
And having to mark every file as "safe" before it could be run every time it's edited wouldn't be inconvenient? It wouldn't just be inconvenient, it would completely break any compiler, script generator, or other software development tool that wasn't modified to create "safe" files, including thousands of programs that create executable files in the normal course of their execution, as well as adding multiple burdensome steps to the software development process.
I want to be able to open scripts in the terminal.
You don't open scripts in the Terminal, you open scripts in the shell. The shell doesn't use LaunchServices to open scripts, and LaunchServices doesn't use either the Terminal or the shell to open scripts.
The only scripts normally opened in the terminal are scripts created and run by already-trusted applications that are already executing locally and can only be involved in an exploit if they were _already compromised_.
But the system should warn me, when I erroneously try to open a script loaded from the net.
The browser will not allow you to open a script loaded from the net. Neither will Finder, or any other application using LaunchServices, unless you install a handler for scripts. Terminal is not the handler for scripts, it's the handler for ".term" files, which are XML files saved by Terminal itself, and not something that a non-sophisticated user would ever need to download from the net.
If you download an ordinary Applescript from the net, and open it in Finder, it's opened in the script editor, it's not run. Should the script editor refuse to open "unsafe" applescripts? If so, how would you examine the applescript to determine if it's "safe" or not, since you need to open it in the script editor to read it? You would have to mark it as safe before you opened it to see if it was safe!
So obviously some applications (applications that can run files) check to see if the file is safe before opening it. Others (applications that edit or view files) can open unsafe documents, so you can see if they're safe before you mark them as safe.
BUT...
The last two exploits of this kind didn't involve applications that normally run scripts. They involved a help viewer and a manual page viewer. Since these applications are viewers, they wouldn't have checked, and the exploits would still have worked.
I am convinced the concept of safe applications won't work.
In 30 years as a programmer and system administrator, designing applications that deal with untrusted documents so they do not even have a mechanism by which a document can request it be opened by an unsafe application (even with some kind of 'approval step' by a user) is the only one I've seen that does work.
Your scheme still depends on safe applications - editors and viewers must be assumed to be safe - and falls down there.
It's also one that I've seen people attempt to implement on systems with discretionary access control (like UNIX, Windows, and every other commonly used OS) and failed. It requires a system with mandatory access controls... an "Orange book" B or A class system. There are very few of these implemented, and they are rarely used by anyone outside the military because they're VERY difficult to get right and impose a huge amount of inconvenience.
Somebody said regarding a particular exploit 'This has nothing to do with X86'.
That was me.
You responded by repeating a claim made by a previous message in the thread, wrapped in this "if-then" construct. I assumed that since you were repeating a comment previously made (and that I would presumably knew, since I must have read it before replying to it), you had some reason for it. The only reason I could think of would be that you knew something about the author of the original article, and that's all I was asking for. If you're just playing language games, include me out.
"if (any false proposition) then (any proposition)" is always a true statement regardless of the truth of (any proposition), so it is pointless to make it. I assume you're not making a pointless statement, so you must have reason to believe the statement is not false. If you don't, then you have no point to make.
Like a Launch Services that has a list of apps like Terminal [...]
No, other way around.
Like a LaunchServices that ONLY HAS a list of aps that are designed to be safe, and anything else is an error. Not a "warning", a big bleeping "There is no safe application to handle this file. If you really want to open it, save it and open it by hand with another application, I ain't touching it". Call it "WebServices".
Your recommendation doesn't handle the sample exploit in Mail.app, unfortunately.
If Mail.app doesn't use BOMArchiver the "jpg" file don't have the metadata that says "open in Terminal.app".
I tried it, it said: "/Users/.../Heise.jpg : Illegal image format".
AND in any case, Mail.app has more than enough other problems that need to be fixed, starting with "no overtext or status line showing actual destination of link".
won't a script ( let's call it foo.sh ) still execute ( even without the execute bit set ) if you give the command "bash foo.sh"
Yep, because you executed the command "bash" and passed it "foo.sh".
Now imagine that foo.sh starts with "#!/bin/bash"
When the loader sees that, it reads the first (16-byte) word of the file (#!) and reads a line "/bin/bash".
So now it executes the command "/bin/bash" and passes it "foo.sh" as an argument.
Which is EXACTLY what you ran when you typed "bash foo.sh".
All the execute bit does is tell the loader (not the shell, the loader, in the kernel) to look in the first 16-bit word of the file to see how to load it.
require an execute bit be set for Terminal.app to open a 'command file' as the Terminal help file stupidly calls them
Dude, THE EXECUTE BIT IS SET, otherwise bash wouldn't have tried to run it as a command (rather than as an argument to/bin/bash).
I'd still prefer to be able to look at a file, or have a web browser or mail program look at a file, and tell me if it's going to run as a script or macro
You can. If the execute bit isn't set, bash won't run it _as a command_. It will still run it _as an argument to the bash command_, but Terminal.app passes it as a _command_, not as an _argument_.
-----
And none of this matters, because the browser SHOULD NOT be using LaunchServices to run commands in the first place.
I recommend preventing the whole class of exploits by turning off "Open Safe Files", installing Stuffit Expander (but turning off "Mount disk images" in there) and not worrying about "Watch non-default application launches".
The problem is that someone used the wrong definition of "safe file".
That's true.
There's no definition of "safe file" that can be stretched to include any file recieved from outside the local protection domain. All files recieved from outside the local protection domain (the local computer and any servers in the local protection boundary managed by someone trusted by the owner of the computer) are assumed unsafe, and must only be opened outside a sandboxed environment by request of a human.
The sandboxed environment in this case consists of the web browser, internet plug ins, and any applications explicitly defined as capable of safely handling untrusted/unsafe files. LaunchServices is not explicitly defined as capable of safely handling untrusted/unsafe files (that's why Safari limits 'open files after downloading' at all). Therefore, Safari should not be using LaunchServices to open files automatically... it should wait for a human to request the files be opened, or it should maintain its own database of safe applications *and* its own mechanism for opening files that doesn't involve the use of an unsafe interface, or it should use a system-maintained database of safe applications.
The rest of this message is a historical note, you can ignore it.
Safari used a different definition: Executable files, and files that contain a pattern that is typical, but not required, for script files.
Er, no. Safari used a different definition: Files beginning with a 'magic number'. The first two bytes of any executable file on UNIX determiine which loader the kernel will use to load the file. For example, on PDP-11 UNIX if the first two bytes were octal 04 and 07 the file was a normal a.out format executable. If they were 04 and 011 it was a split-instruction-and-data executable. If they were '#' and '!' the loader read the rest of the line to find the name of the program to execute the file.
The thing is, that on V6 unix and early V7, the #! magic number wasn't magic at all... but shell scripts still had to be executed. What happened then was that the shell would open and execute the file as a series of shell commands... for the early shells (V6 and earlier) it literally set standard input to the script and just continued running, if the file had the execute bit set.
And THAT is why the shell (/bin/bash) inside the Terminal ran the file as a script. Because it's retaining compatibility with the way the V6 shell _had_to_ work in 1976.
How the '#!' string came about, that'll be a story for another day.
Abandon Finder and start over with the NeXTStep File Manager. Stop using metadata for icons and file handlers and keep all that info separately from the files. Abandon "Open Safe Files After Download" and replace it with a system like LaunchServices but restricted to applications that are intended to handle "unsafe" files.
there *should* be some sort of way to tell if a file is going to execute in some manner
There is. It's called "the execute bit". If the execute bit is set, then the file it's set on is executed. If it can't be executed by the kernel (based on the magic number on the first to bytes of the file), it's executed by the shell directly.
The real bug is in Terminal.app - it runs scripts even if they don't start with the shebang
Terminal.app does no such thing. It simply passes on whatever you give it to/bin/sh, which it's supposed to do.
It's not a bug in/bin/sh either. The POSIX standard specifies that if the shell fails to execute the script using exec(), if the execute bit is set it should run it itself.
The "bug" is a pair of known design flaws in Safari that Apple should have fixed two years ago, along with a change in the unzipper that changed the behaviour Safari was mistakenly depending on.
If this particular incident is the result of whoever exploited it discovering it because they were playing with OSx86 then it is related to the switch.
Please provide the evidence that you have for the claim that this exploit was the result of someone playing with OSX86.
Regardless of whether this particular exploit works on 10.2.8, if you use Safari on any version of Mac OS X you should still disable "Open Safe Files After Downloading" to prevent any related attacks that may be devised that do work on 10.2.8...
As soon as more eyes go into looking at security holes, wow, truth revealed.
Errrr... let's see.
OS X: all related automatic execution attacks are prevented by changing one setting in the default browser.
Windows: the only way to prevent comparable automatic execution attacks is to remove the browser, which disables software updates, many control panel applets and other essential system tools, and several unrelated applications.
I'm not sure I understand your point, can you elaborate?
If you feel that your computer is involnerable to hacks you will get hack eventually.
Not necessarily. Marcus Ranum's Perfect Firewall is still 100% effective, as far as I know, and I can't imagine a network-based attack that could bypass it. But I doubt someone who can't spell "invulnerable" would know about it.
Which means you'll leave "Open Safe Files" enabled, keep using BOMArchiver to unzip files... and get caught when the bad guy uses [REDACTED] or [REDACTED].
Shiira doesn't have a preferences option for automatically opening downloaded files at all, and allows you to choose using Webkit or cURL for the download.
[ecode] Camino Preferences --> Downloads --> When Downloads Finish:
[] Open downloaded files.
Downloaded files can be passed off to other "helper" applications. While convenient, enabling this feature makes your computer vulnerable to damaging programs. [/ecode] 1. Not enabled by default.
Slashdot Mirror
Not specifically because of the "piracy" of Mac OS X (and I'm not certain that it should actually be called "piracy" - even in the colloquial sense - to buy a copy of Mac OS X and install it on a non-Mac, even if the EULA is enforcable), but the TPM capability of the Intel chipset does make Open Source Darwin a problem. Releasing the source to the OS without making it possible to use the source to bypass any strong DRM Apple happened to have a use for just becomes harder and more expensive.
First, the "." chaarcter in a UNIX file name doesn't separate the name from the extension. It's just another character. UNIX applications have traditionally used the first or last few characters of the name for a variety of reasons, but that's just a convention and you find things like "s.file" or "file,v" or "file~" or "._file", as well as applications using 'magic numbers' in the first few characters of the file... like "#!" or "%!PS" or ": ".
And the UNIX shell didn't use filename extensions to determine the application to run files. The UNIX shell uses a verb-noun syntax, not the object-action syntax of modern GUIs. The application was explicitly named in the first word of the command.
The extended UNIX 'ls' command from BSD, the one that established the convention of using "*", "/", "@", and so on at the end of file names to indicate the file's metatdata, payed no attention to the name itself to determine how to display a file.
Many individual GUI file managers on UNIX have, but the majority of GUI file managers on UNIX are copied from Windows, one way or another. The ones that are older typically made "deeper" decisions... I've had mail folders with no extensions at all show up as a little 'in tray', based on the contents of the file.
Windows file extensions are based on the DOS 1.x "8 character name plus 3 character type", which was based on the CP/M 6+3 filename, which was based on the ISIS 6+3 filename, which was based on DEC's RT- and RSX- operating systems that used 6+3 filenames.
They started out as a genuine file type, like the Mac creator and type Finder Info, which is why they are considered "strong" type information rather than "weak" type information. It's a pity that the OS X Finder didn't follow the early UNIX precedent of considering all 'creator/content' meta-information as "weak", and using the file itself as the primary source... the way the UNIX commands "ls" and "file" do.
why the heck doesn't Safari or Mail notice that ( even just one file of ) the attachment has the execute bit set and sound the warning bell ?
/bin/bash. I'm not going to go into details, but if you think about all the other scripting languages available on OS X you should be able to think of some approaches.
That's the wrong question, because there's other ways to sneak a script past Safari using LaunchServices that don't involve having the execute bit set or any other indication that the document is a script, that don't involve Terminal or
LaunchServices has been involved in two other exploits similar to this one in the past, and the changes that Apple made to "fix" them were superficial... this exploit is proof of that.
The right question is, why does Safari or Mail have to trust LaunchServices, when LaunchServices is by design not a safe way to open untrusted documents?
Nope, they try something different: They try to implement a zone model.
They also implement a Zone model, as well as using signed "safe" documents that may contain active content. Originally the "safe documents" model unconditionally overrode the zone model - signed documents were trusted in all zones. That enabled exploits piggybacking on trusted documents, so the zone model (which I agree is broken) now overrides the "safe documents" model.
Active X is somewhat similar to the safe application model.
Not in any sense. Active X components are documents in the "safe application" model, not applications. Safe applications are applications that are installed by the user or the system vendor and registered by the creator after explicit installation as providing a "sandboxed" environment in which unsafe documents can be examined. Any object received from an untrusted source is an "unsafe document" regardless of whether it contains active content or not.
I don't want to have a full blown rigorous mandatory access control (MAC)security model on my Mac.
Anything less creates a false sense of security.
The system should interact with most of the existing tools, should be easy to understand and should let the user [have] the last word.
The "safe applications" model satisfies all these requirements, AND over the past 10 years since Microsoft made 'drive-by execution' the norm it has proven itself time and time again.
I have more than 100 users that range from the naive to "top geeks". I have had people repeatedly come to me and say "um, Peter, I clicked on the wrong button again and I think I have a virus" same people, over and over again, because the zones-plus-trusted-documents model requires the user to routinely approve potentially dangerous actions... so they're trained to hit "yes", "open", "launch", "infect me", or whatever the interface-of-the-week pops up. I've never had someone come to me more than once and say "Peter, I downloaded a file, opened my downloads directory, and double clicked on the file, and now I'm infected". Not once, not even the people I have to walk through selecting a printer every week.
Most of the infections we got were from people reflexively approving an infection... despite the fact that most of the time IE (along with its related apps) was banned and only half a dozen *technical* people were allowed to use it.
The "safe documents" model requires all new tools, is complex and hard to understand, and - unless it's made grossly inconvenient by forcing the user to back out of partially completed actions and return to the Finder to explicitly change the state of applications - it will train the user to reflexively approve annoying dialog boxes.
stop double-clicking files to open them.
Yep, dragging them or selecting the app using "open with" is definitely recommended, particularly for files you just downloaded. Not just for security, but also to avoid annoyances.
One thing I've found is that a lot of files in disk images or stuffit archives (by the by, stuffit archives ALSO maintain the dangerous metadata) have the "wrong" default application anyway. I use Camino as my browser, for example, and for a long time I used the PDF plugin for PDFs so Camino was my PDF viewer as well. Typically, HTML help files and PDF docs would open in Safari (or, in some cases, Internet Explorer!) and Preview if I didn't override them.
You can just add some more attributes to define exceptions and refine the scheme.
...applying the "safe application" model from the browser absolutely prevents those exploits and any variation of those exploits from happening, and when a bug *is* found in a safe application it takes less than 15 minutes to fix it... without forcing the user to deal with the problem outside the browser.
You can't fix this scheme, not without ending up with "safe" applications anyway.
No, I'm not adding more attributes, I'm describing what would be required if you actually implemented this scheme.
If I edit "/etc/rc" in "vi" then the next time the system comes up "/bin/bash" will open "/etc/rc" and go "/etc/rc was edited by vi, I'm not going to run" and you won't even be able to get into single-user mode.
If I edit the configuration file for Apache (shipped by Apple) with TextEdit (shipped by Apple) then Apache won't run.
This situation, where a program is created by one application and used by another is all over the place.
Now you have to have both "safe applications" (such as viewers) and "safe editors". So your scheme reduces to a "safe application" model, but one that is intrusive and provides a false sense of security, because...
Fair enough, my proposal won't stop such exploits in the first place.
Microsoft has been attempting to get the scheme you're proposing working since 1997, and they're only trying to do it for a *subset* of the domain you're talking about. When they implemented it in the first place they did such a bad job that they created the worst storm of viruses and email worms the net had ever seen. Over a couple of years the number of active exploits of Microsoft's trust model turned viruses from a minor problem that you could easily avoid by a few simple habits to the biggest problem on the net... I'm seeing gigabytes of just rejected viruses and worms a month.
The only way to make "trusted files" work is to go to mandatory access control, and the amount of inconvenience that imposes is insane.
Security must be as convenient as possible or the user will circumvent the security measures.
Which is why limiting untrusted documents to only trusted applications unless a human explicitly requests that the document be opened outside the sandbox is the only model that works for a large population of users. It's convenient, and effective.
It requires a minimal level of sophistication from the user, yes, but people are actually LESS likely to mistakenly tell the system to trust something they shouldn't than in the scheme you propose.
This would either be very inconvenient or it would need a very savvy user.
And having to mark every file as "safe" before it could be run every time it's edited wouldn't be inconvenient? It wouldn't just be inconvenient, it would completely break any compiler, script generator, or other software development tool that wasn't modified to create "safe" files, including thousands of programs that create executable files in the normal course of their execution, as well as adding multiple burdensome steps to the software development process.
I want to be able to open scripts in the terminal.
You don't open scripts in the Terminal, you open scripts in the shell. The shell doesn't use LaunchServices to open scripts, and LaunchServices doesn't use either the Terminal or the shell to open scripts.
The only scripts normally opened in the terminal are scripts created and run by already-trusted applications that are already executing locally and can only be involved in an exploit if they were _already compromised_.
But the system should warn me, when I erroneously try to open a script loaded from the net.
The browser will not allow you to open a script loaded from the net. Neither will Finder, or any other application using LaunchServices, unless you install a handler for scripts. Terminal is not the handler for scripts, it's the handler for ".term" files, which are XML files saved by Terminal itself, and not something that a non-sophisticated user would ever need to download from the net.
If you download an ordinary Applescript from the net, and open it in Finder, it's opened in the script editor, it's not run. Should the script editor refuse to open "unsafe" applescripts? If so, how would you examine the applescript to determine if it's "safe" or not, since you need to open it in the script editor to read it? You would have to mark it as safe before you opened it to see if it was safe!
So obviously some applications (applications that can run files) check to see if the file is safe before opening it. Others (applications that edit or view files) can open unsafe documents, so you can see if they're safe before you mark them as safe.
BUT...
The last two exploits of this kind didn't involve applications that normally run scripts. They involved a help viewer and a manual page viewer. Since these applications are viewers, they wouldn't have checked, and the exploits would still have worked.
I am convinced the concept of safe applications won't work.
In 30 years as a programmer and system administrator, designing applications that deal with untrusted documents so they do not even have a mechanism by which a document can request it be opened by an unsafe application (even with some kind of 'approval step' by a user) is the only one I've seen that does work.
Your scheme still depends on safe applications - editors and viewers must be assumed to be safe - and falls down there.
It's also one that I've seen people attempt to implement on systems with discretionary access control (like UNIX, Windows, and every other commonly used OS) and failed. It requires a system with mandatory access controls... an "Orange book" B or A class system. There are very few of these implemented, and they are rarely used by anyone outside the military because they're VERY difficult to get right and impose a huge amount of inconvenience.
Somebody said regarding a particular exploit 'This has nothing to do with X86' .
That was me.
You responded by repeating a claim made by a previous message in the thread, wrapped in this "if-then" construct. I assumed that since you were repeating a comment previously made (and that I would presumably knew, since I must have read it before replying to it), you had some reason for it. The only reason I could think of would be that you knew something about the author of the original article, and that's all I was asking for. If you're just playing language games, include me out.
Do you not understand English
I understand logic.
"if (any false proposition) then (any proposition)" is always a true statement regardless of the truth of (any proposition), so it is pointless to make it. I assume you're not making a pointless statement, so you must have reason to believe the statement is not false. If you don't, then you have no point to make.
Like a Launch Services that has a list of apps like Terminal [...]
No, other way around.
Like a LaunchServices that ONLY HAS a list of aps that are designed to be safe, and anything else is an error. Not a "warning", a big bleeping "There is no safe application to handle this file. If you really want to open it, save it and open it by hand with another application, I ain't touching it". Call it "WebServices".
Your recommendation doesn't handle the sample exploit in Mail.app, unfortunately.
If Mail.app doesn't use BOMArchiver the "jpg" file don't have the metadata that says "open in Terminal.app".
I tried it, it said: "/Users/.../Heise.jpg : Illegal image format".
AND in any case, Mail.app has more than enough other problems that need to be fixed, starting with "no overtext or status line showing actual destination of link".
won't a script ( let's call it foo.sh ) still execute ( even without the execute bit set ) if you give the command "bash foo.sh"
/bin/bash).
Yep, because you executed the command "bash" and passed it "foo.sh".
Now imagine that foo.sh starts with "#!/bin/bash"
When the loader sees that, it reads the first (16-byte) word of the file (#!) and reads a line "/bin/bash".
So now it executes the command "/bin/bash" and passes it "foo.sh" as an argument.
Which is EXACTLY what you ran when you typed "bash foo.sh".
All the execute bit does is tell the loader (not the shell, the loader, in the kernel) to look in the first 16-bit word of the file to see how to load it.
require an execute bit be set for Terminal.app to open a 'command file' as the Terminal help file stupidly calls them
Dude, THE EXECUTE BIT IS SET, otherwise bash wouldn't have tried to run it as a command (rather than as an argument to
I'd still prefer to be able to look at a file, or have a web browser or mail program look at a file, and tell me if it's going to run as a script or macro
You can. If the execute bit isn't set, bash won't run it _as a command_. It will still run it _as an argument to the bash command_, but Terminal.app passes it as a _command_, not as an _argument_.
-----
And none of this matters, because the browser SHOULD NOT be using LaunchServices to run commands in the first place.
I recommend preventing the whole class of exploits by turning off "Open Safe Files", installing Stuffit Expander (but turning off "Mount disk images" in there) and not worrying about "Watch non-default application launches".
But turning "Watch URI schemes" on is worth considering, because Apple's solution doesn't actually prevent the exploit that led to its creation.
The problem is that someone used the wrong definition of "safe file".
That's true.
There's no definition of "safe file" that can be stretched to include any file recieved from outside the local protection domain. All files recieved from outside the local protection domain (the local computer and any servers in the local protection boundary managed by someone trusted by the owner of the computer) are assumed unsafe, and must only be opened outside a sandboxed environment by request of a human.
The sandboxed environment in this case consists of the web browser, internet plug ins, and any applications explicitly defined as capable of safely handling untrusted/unsafe files. LaunchServices is not explicitly defined as capable of safely handling untrusted/unsafe files (that's why Safari limits 'open files after downloading' at all). Therefore, Safari should not be using LaunchServices to open files automatically... it should wait for a human to request the files be opened, or it should maintain its own database of safe applications *and* its own mechanism for opening files that doesn't involve the use of an unsafe interface, or it should use a system-maintained database of safe applications.
The rest of this message is a historical note, you can ignore it.
Safari used a different definition: Executable files, and files that contain a pattern that is typical, but not required, for script files.
Er, no. Safari used a different definition: Files beginning with a 'magic number'. The first two bytes of any executable file on UNIX determiine which loader the kernel will use to load the file. For example, on PDP-11 UNIX if the first two bytes were octal 04 and 07 the file was a normal a.out format executable. If they were 04 and 011 it was a split-instruction-and-data executable. If they were '#' and '!' the loader read the rest of the line to find the name of the program to execute the file.
The thing is, that on V6 unix and early V7, the #! magic number wasn't magic at all... but shell scripts still had to be executed. What happened then was that the shell would open and execute the file as a series of shell commands... for the early shells (V6 and earlier) it literally set standard input to the script and just continued running, if the file had the execute bit set.
And THAT is why the shell (/bin/bash) inside the Terminal ran the file as a script. Because it's retaining compatibility with the way the V6 shell _had_to_ work in 1976.
How the '#!' string came about, that'll be a story for another day.
there's no real fix possible to this issue.
Abandon Finder and start over with the NeXTStep File Manager. Stop using metadata for icons and file handlers and keep all that info separately from the files. Abandon "Open Safe Files After Download" and replace it with a system like LaunchServices but restricted to applications that are intended to handle "unsafe" files.
there *should* be some sort of way to tell if a file is going to execute in some manner
There is. It's called "the execute bit". If the execute bit is set, then the file it's set on is executed. If it can't be executed by the kernel (based on the magic number on the first to bytes of the file), it's executed by the shell directly.
The real bug is in Terminal.app - it runs scripts even if they don't start with the shebang
/bin/sh, which it's supposed to do.
/bin/sh either. The POSIX standard specifies that if the shell fails to execute the script using exec(), if the execute bit is set it should run it itself.
Terminal.app does no such thing. It simply passes on whatever you give it to
It's not a bug in
The "bug" is a pair of known design flaws in Safari that Apple should have fixed two years ago, along with a change in the unzipper that changed the behaviour Safari was mistakenly depending on.
I mean like "click here to watch" links
They are still opened by the plugin in a browser window.
If this particular incident is the result of whoever exploited it discovering it because they were playing with OSx86 then it is related to the switch.
Please provide the evidence that you have for the claim that this exploit was the result of someone playing with OSX86.
Regardless of whether this particular exploit works on 10.2.8, if you use Safari on any version of Mac OS X you should still disable "Open Safe Files After Downloading" to prevent any related attacks that may be devised that do work on 10.2.8...
As soon as more eyes go into looking at security holes, wow, truth revealed.
Errrr... let's see.
OS X: all related automatic execution attacks are prevented by changing one setting in the default browser.
Windows: the only way to prevent comparable automatic execution attacks is to remove the browser, which disables software updates, many control panel applets and other essential system tools, and several unrelated applications.
I'm not sure I understand your point, can you elaborate?
If you feel that your computer is involnerable to hacks you will get hack eventually.
Not necessarily. Marcus Ranum's Perfect Firewall is still 100% effective, as far as I know, and I can't imagine a network-based attack that could bypass it. But I doubt someone who can't spell "invulnerable" would know about it.
Which means you'll leave "Open Safe Files" enabled, keep using BOMArchiver to unzip files... and get caught when the bad guy uses [REDACTED] or [REDACTED].
Shiira doesn't have a preferences option for automatically opening downloaded files at all, and allows you to choose using Webkit or cURL for the download.
[ecode]
Camino Preferences --> Downloads --> When Downloads Finish:
[] Open downloaded files.
Downloaded files can be passed off to other "helper" applications. While convenient, enabling this feature makes your computer vulnerable to damaging programs.
[/ecode]
1. Not enabled by default.
2. Tells you that enabling it is a stupid idea.