So after all that response, you still can't tell that the point is you cannot tell what kind of file a file is? You'd have to solve the halting problem, and worse.
You said 'Yup, that would be the definition of "computer virus".' in response to "So, this is a "virus" that is nothing more than something that programmatically attaches/appends itself to other files". That's what I was responding to. My little script does exactly that (well, once you remove the "echo" disabler).
Anyone who knows how viruses work would recognize that the unstated assertion "in such a way that the virus will be executed when the host program is run" is there. In the original context, it was implied that OSX.Macarena would only live one generation. I don't have my own copy for analysis yet, but the few writeups I've seen do not indicate any such restriction. AV companies are generally very careful with their terminology, and I would be surprised to have them label something a "virus" that wasn't.
As for getting root access as an Admin without entering a password, I don't know of any ways to do it http://apple.slashdot.org/article.pl?sid=06/09/16/ 182207 (And it's not a "bug", its a supported API) Apple really should yank it.
I certainly don't have my primary login set to be admin, there's no need for it. But that's the default setup for a new Mac user when they unbox their machine, right?
"an executable" - something that, when you double-click it, runs the content in the file as a suitably general-purpose program. A "non-executable" - something that, when you double-click it, runs a program that, barring bugs, will NOT execute general-purpose program code.
So then Word files, text files, DMG files, HTML files, various compressed file formats, are executables?
OS X has various rules for determining what happens when you double-click on a file, or click on an attachment in e-mail. Given those rules, and given a list of "safe" and "not safe" interpreters, you can determine which are a problem and which are not.
Ah, so you mean to say that given a single configuration of a single Mac, and pick a subset of interpreters, you can determine if every possible is a virus or not?
No halting problem. Not trying to analyze a JPEG viewer and determine if it has a bug in it that lets you execute arbitrary code. Simply a declaration that a JPEG viewing program does not intend to implement a general-purpose programming environment with sufficient capability to modify or otherwise affect the system or other processes, thus a JPEG file is not to be considered an "executable".
But what if some JPEG viewers have such a bug? What if some do implement a programming language? What if it's labeled "JPEG", but is in fact some other file format, and the JPEG viewer does multiple formats, and picks the "right" one? What if half of a virus is using JPEG files to store its other half?
Are you so sure you never need to consider JPEG files as being dangerous?
I store my Tcl scripts in a file called ".tcl", or one having the executable bit set and the first line of the file containing "#!/bin/sh" or "#!/usr/bin/tclsh";
Is it now no longer a text file?
Hey, if you rename that same TCL file to.jpg and run it from the shell, what happens?
That was the point, that simply copying yourself to any and all files does not a virus make.
Indeed. What does that have to do with OSX.Macarena?
If you're Admin on a non-hardened OS X, then you can also be root, just add code. No password prompt required. Plus, you can infect everything in/Applications, which is to say, pretty much every app on the box. Practically speaking, there's no difference between someone in the admin group and root, as it stands.
You don't need to invoke the halting problem to determine what is and isn't an executable.
Sure you do.
for example a Perl or Python or Tcl script is, by intent, capable of self-replicating and spreading itself. snip A text or JPEG file is not, barring bugs in the program displaying it.
So exactly what kinds of files are you keeping your perl, Python or TCL scripts in?
They were file infecters, and also installed listeners and phoned home. They tried to use a couple of minor stealth features, but I don't think you could call them rootkits.
Which "this"? Are we arguing semantics about "virus" in this thread? If yes, any reasonable person who know how viruses work realizes that "attaches/appends itself to other files" means, in this context that it does it correctly in such a way that the code executes when the host is run, and therefore propagates.
Or are you saying "this" as in OSX.Macarena? If so, why do you think it doesn't propagate?
You'll want to insert yourself at the beginning of the file to be sure you run, not at the end. And it would be helpful to make sure it's a shell script you're modifying so you don't trash the host file functionality.
For instance, in earlier versions of OS X, there were a lot of directories and files that were writable by group "admin",
Earlier? Are they going to fix this in 10.5 or something?
(On 10.4.8)
ryan-russells-ibook-g4:~ ryanlrussell$ ls -ald/Applications/ drwxrwxr-x 52 root admin 1768 Oct 25 15:59/Applications/
I suppose you could argue that an operating system should block ANY "generally executable" code from being written to any file without explicit user notification/validation.
Actually, I think that's technically known as a worm. Viruses, in turn, are a damaging form of worm.
No, not at all. A worm propagates itself without the need to attach itself to a host container. Wikipedia has an adequate introduction. The misused/abused common meaning aren't terribly useful for this kind of discussion.
And where is that encoded by either inclusion or exclusion in the lsit of things I am allowed to do? As a mechanical act, ripping is no different than playing.
My point is that (I believe) "playing" is also not explictly permitted. It's simply clear to everyone involved that it's allowed. If that's the basis for allowing playing, why can't ripping be allowed in the same way?
OK, I was trying to see if it was deeper than that. AFAIK, copyright law doesn't spell out exactly what your rights are when you buy a copy of a recording. And not all CDs spell out your "license" terms. Which just leaves "everyone knows you're allowed to listen to a CD you bought." As in, a jury of my peers knows that, and would back me up on it.
Or am I wrong on that?
Because if that's the basis that lets me listen to my CD I bought, that leaves:
-I have no right to rip to an iPod, OR -I'm good if the CD doesn't disclaim my right to rip to an iPod (only a few have disclaimed that) -I'm good if EULAs don't hold up in court (not well tested) -I'm good if everyone knows I'm allowed to rip CDs to my iPod, including a jury of my peers
DMCA shouldn't enter into it, because the vast majority of CDs don't have a protection mechanism.
Not code on the stack since OS X uses the NX bit on the stack by default
So, is NX support enabled on kernel pages?
Some code in a buffer? How do you find the address of the buffer? How do you inject the code into the buffer in the first place?
Right, so you want to know some basic buffer overflow exploitation techniques. I think I've got a book somewhere that some friends and I wrote, it covers that...
Yeah, I'm sure no one will mind if Verizon gives out customer info without a subpoena. A phone company would only do that kind of thing under rare circumstances.
My publisher likes bookpool. They will do special promotions, they tend to be able to sell my books for the best prices, and we still make a little better margin with them.
I believe I looked at the original article before they updated it. Is there a copy somewhere?
Are you saying that you know there are exploits for these two eeye quicktime vulnerabilities,
They say Quicktime/iTunes. The eEye guys pretty much always produces a working exploit before they report anything to the vendor. I haven't written any of them to confirm, and I don't have copies. (They play fair with the vendors generally, and don't give out their in-house exploits.)
or that you know of the existence of vulnerabilities
And I know of other vulnerabilities.
and also know of the existence of the exploits for the Safari and Bluetooth vulnerabilities everyone knows about. Your language is somewhat ambiguous.
And I have exploits for those two, not written by me.
Listing potential vulnerabilities is not the issue. We're talking exploits, not vulnerabilities.
That's why I only listed some items that I know have had exploits written for them. If you want a list of vulnerabilities instead, you can look at Apple's big recent update.
To get back on the point, what makes you think the first article had information about the local accounts being given out and what makes you think the second challenge did not disprove the article's misleading depiction?
That I read the first one, and knew from it that they attackers were given a shell.
I don't know of any Ryan R. with a notable security reputation
I can't speak to how notable it is. But my name is Ryan Russell, I am sometimes more easily remembered as Blue Boar.
Here's a list of the books I've worked on. You can see some of my co-authors, for example.
In the Apple case in particular, I've had early access to KF's Bluetooth stuff, for example. I also have a copy of the local priv escalation exploit that was used in the first contest. And of course, there are people out there that are much better connected exploit-wise than I.
Slashdot Mirror
I take it you disagree. Do you have an example?
Keep in mind that for a virus researcher, "virus" means something specific, not just some general "bad" program. See: entire rest of this thread.
So after all that response, you still can't tell that the point is you cannot tell what kind of file a file is? You'd have to solve the halting problem, and worse.
You said 'Yup, that would be the definition of "computer virus".' in response to "So, this is a "virus" that is nothing more than something that programmatically attaches/appends itself to other files". That's what I was responding to. My little script does exactly that (well, once you remove the "echo" disabler).
/ 182207
.jpg and run it from the shell, what happens?
Anyone who knows how viruses work would recognize that the unstated assertion "in such a way that the virus will be executed when the host program is run" is there. In the original context, it was implied that OSX.Macarena would only live one generation. I don't have my own copy for analysis yet, but the few writeups I've seen do not indicate any such restriction. AV companies are generally very careful with their terminology, and I would be surprised to have them label something a "virus" that wasn't.
As for getting root access as an Admin without entering a password, I don't know of any ways to do it
http://apple.slashdot.org/article.pl?sid=06/09/16
(And it's not a "bug", its a supported API)
Apple really should yank it.
I certainly don't have my primary login set to be admin, there's no need for it.
But that's the default setup for a new Mac user when they unbox their machine, right?
"an executable" - something that, when you double-click it, runs the content in the file as a suitably general-purpose program. A "non-executable" - something that, when you double-click it, runs a program that, barring bugs, will NOT execute general-purpose program code.
So then Word files, text files, DMG files, HTML files, various compressed file formats, are executables?
OS X has various rules for determining what happens when you double-click on a file, or click on an attachment in e-mail. Given those rules, and given a list of "safe" and "not safe" interpreters, you can determine which are a problem and which are not.
Ah, so you mean to say that given a single configuration of a single Mac, and pick a subset of interpreters, you can determine if every possible is a virus or not?
No halting problem. Not trying to analyze a JPEG viewer and determine if it has a bug in it that lets you execute arbitrary code. Simply a declaration that a JPEG viewing program does not intend to implement a general-purpose programming environment with sufficient capability to modify or otherwise affect the system or other processes, thus a JPEG file is not to be considered an "executable".
But what if some JPEG viewers have such a bug? What if some do implement a programming language? What if it's labeled "JPEG", but is in fact some other file format, and the JPEG viewer does multiple formats, and picks the "right" one? What if half of a virus is using JPEG files to store its other half?
Are you so sure you never need to consider JPEG files as being dangerous?
I store my Tcl scripts in a file called ".tcl", or one having the executable bit set and the first line of the file containing "#!/bin/sh" or "#!/usr/bin/tclsh";
Is it now no longer a text file?
Hey, if you rename that same TCL file to
That was the point, that simply copying yourself to any and all files does not a virus make.
/Applications, which is to say, pretty much every app on the box. Practically speaking, there's no difference between someone in the admin group and root, as it stands.
Indeed. What does that have to do with OSX.Macarena?
If you're Admin on a non-hardened OS X, then you can also be root, just add code. No password prompt required. Plus, you can infect everything in
You don't need to invoke the halting problem to determine what is and isn't an executable.
Sure you do.
for example a Perl or Python or Tcl script is, by intent, capable of self-replicating and spreading itself. snip A text or JPEG file is not, barring bugs in the program displaying it.
So exactly what kinds of files are you keeping your perl, Python or TCL scripts in?
They were file infecters, and also installed listeners and phoned home. They tried to use a couple of minor stealth features, but I don't think you could call them rootkits.
RST.a
RST.b
OSF
Which "this"? Are we arguing semantics about "virus" in this thread? If yes, any reasonable person who know how viruses work realizes that "attaches/appends itself to other files" means, in this context that it does it correctly in such a way that the code executes when the host is run, and therefore propagates.
Or are you saying "this" as in OSX.Macarena? If so, why do you think it doesn't propagate?
You'll want to insert yourself at the beginning of the file to be sure you run, not at the end. And it would be helpful to make sure it's a shell script you're modifying so you don't trash the host file functionality.
For instance, in earlier versions of OS X, there were a lot of directories and files that were writable by group "admin",
Earlier? Are they going to fix this in 10.5 or something?
(On 10.4.8) I suppose you could argue that an operating system should block ANY "generally executable" code from being written to any file without explicit user notification/validation.
Halting problem says what?
Actually, I think that's technically known as a worm. Viruses, in turn, are a damaging form of worm.
No, not at all. A worm propagates itself without the need to attach itself to a host container. Wikipedia has an adequate introduction. The misused/abused common meaning aren't terribly useful for this kind of discussion.
This isn't the "first" proof-of-concept for OS X that meets the definition of a "virus".
I'd love a pointer. I spent some time actively looking, and didn't have any luck.
when will we stop hearing about each and every new piece of malware for Mac OS X when they're not even novel, new, or interesting anymore?
When they are not novel, new, or interesting anymore. Sadly, that will be where there is actually a real problem.
So, this is a "virus" that is nothing more than something that programmatically attaches/appends itself to other files
Yup, that would be the definition of "computer virus".
No, not particularly threatening. It doesn't appear to be designed to be. It does mean that OS X has had its virus cherry popped, though.
I'm trying to keep track of OS X malware here. The levels seem remarkably low so far.
The Linux in-the-wild score is incorrect.
I've personally analyzed at least three Linux viruses that were found in the wild. And that's not counting the worms.
Thanks! Glad you enjoyed it.
And where is that encoded by either inclusion or exclusion in the lsit of things I am allowed to do? As a mechanical act, ripping is no different than playing.
My point is that (I believe) "playing" is also not explictly permitted. It's simply clear to everyone involved that it's allowed. If that's the basis for allowing playing, why can't ripping be allowed in the same way?
OK, I was trying to see if it was deeper than that. AFAIK, copyright law doesn't spell out exactly what your rights are when you buy a copy of a recording. And not all CDs spell out your "license" terms. Which just leaves "everyone knows you're allowed to listen to a CD you bought." As in, a jury of my peers knows that, and would back me up on it.
Or am I wrong on that?
Because if that's the basis that lets me listen to my CD I bought, that leaves:
-I have no right to rip to an iPod, OR
-I'm good if the CD doesn't disclaim my right to rip to an iPod (only a few have disclaimed that)
-I'm good if EULAs don't hold up in court (not well tested)
-I'm good if everyone knows I'm allowed to rip CDs to my iPod, including a jury of my peers
DMCA shouldn't enter into it, because the vast majority of CDs don't have a protection mechanism.
So are you claiming that there is no "listening right" even if I'm just talking about playing the original CD in a standard CD player?
Name one remote attack vector on a default system and get back to me.
Didn't you get the DHCP patch?
What are you going to point EIP to?
All kinds of fun places.
Not code on the stack since OS X uses the NX bit on the stack by default
So, is NX support enabled on kernel pages?
Some code in a buffer? How do you find the address of the buffer? How do you inject the code into the buffer in the first place?
Right, so you want to know some basic buffer overflow exploitation techniques. I think I've got a book somewhere that some friends and I wrote, it covers that...
I'm curious about what OSes you're using that are protected from buggy or hostile device drivers...
So, are you not familiar with EIP, then?
That's a fair suggestion, depending on Verizon's policies. As long as there is a case number, Verizon could contact the police and provide info.
Yeah, I'm sure no one will mind if Verizon gives out customer info without a subpoena. A phone company would only do that kind of thing under rare circumstances.
Never?
y nor&sbm=bid&submit=Search%21&metaname=alldoc&sort= swishrank
http://search.securityfocus.com/swsearch?query=ma
My publisher likes bookpool. They will do special promotions, they tend to be able to sell my books for the best prices, and we still make a little better margin with them.
I believe I looked at the original article before they updated it. Is there a copy somewhere?
Are you saying that you know there are exploits for these two eeye quicktime vulnerabilities,
They say Quicktime/iTunes. The eEye guys pretty much always produces a working exploit before they report anything to the vendor. I haven't written any of them to confirm, and I don't have copies. (They play fair with the vendors generally, and don't give out their in-house exploits.)
or that you know of the existence of vulnerabilities
And I know of other vulnerabilities.
and also know of the existence of the exploits for the Safari and Bluetooth vulnerabilities everyone knows about. Your language is somewhat ambiguous.
And I have exploits for those two, not written by me.
Listing potential vulnerabilities is not the issue. We're talking exploits, not vulnerabilities.
That's why I only listed some items that I know have had exploits written for them. If you want a list of vulnerabilities instead, you can look at Apple's big recent update.
To get back on the point, what makes you think the first article had information about the local accounts being given out and what makes you think the second challenge did not disprove the article's misleading depiction?
That I read the first one, and knew from it that they attackers were given a shell.
I don't know of any Ryan R. with a notable security reputation
I can't speak to how notable it is. But my name is Ryan Russell, I am sometimes more easily remembered as Blue Boar.
Here's a list of the books I've worked on. You can see some of my co-authors, for example.
In the Apple case in particular, I've had early access to KF's Bluetooth stuff, for example. I also have a copy of the local priv escalation exploit that was used in the first contest. And of course, there are people out there that are much better connected exploit-wise than I.