Are apparmor profiles available for rhythmbox or Totem?

[Hungry Man]

Run aa-logprof and see what's missing.

It's less that I'm getting the program to do what I want and more that I'm making use of the programs executable address space. But that's pretty much the general idea.

[Hungry Man]

This would be sort of like the Flashback trojan that hit OSX recently. OSX, like Linux, uses a default umask of 022. What this means is that newly created files are not executable by default. However, in the case of Flashback, the user had his browser exploited via a Java flaw, then redirected to a malicious site. At this site, a trojan was downloaded and automatically placed into the users /home folder. This file should not be executable, yet somehow it was.

I guess I just don't understand the Flashback trojan because no one that I have seen has really described (as the lowest levels) how it works. So, because of this, I am kinda confused how it bypassed the no-executable bit.

Java doesn't support ASLR and it barely supports DEP. DEP separates data from code, exec from no-exec. Java just marks everything "exec" so it doesn't matter.

That said, even with proper DEP it's trivial to bypass without ASLR. OSX has awful ASLR anyways.

Because Java is a JIT compiler everything it does is marked executable. So if you exploit Java you're free to use any part of its address space.

I don't know the details of the exploit. If you exploit Java and download the payload you can just use Java to then run the payload without user permission.

[jerome1232]

This would be sort of like the Flashback trojan that hit OSX recently. OSX, like Linux, uses a default umask of 022. What this means is that newly created files are not executable by default. However, in the case of Flashback, the user had his browser exploited via a Java flaw, then redirected to a malicious site. At this site, a trojan was downloaded and automatically placed into the users /home folder. This file should not be executable, yet somehow it was.

Installers for OSX generally come as disc images, double clicking mounts the disk image which autoruns and will have it's own preset permissions. The user doesn't have to mark anything as executable this way.

Trojans will be trojans, they generally exploit the user not the system.

[Hungry Man]

True. But in the case of Flashback it was definitely a case of exploiting the system.

[0011235813]

This would be sort of like the Flashback trojan that hit OSX recently. OSX, like Linux, uses a default umask of 022. What this means is that newly created files are not executable by default. However, in the case of Flashback, the user had his browser exploited via a Java flaw, then redirected to a malicious site. At this site, a trojan was downloaded and automatically placed into the users /home folder. This file should not be executable, yet somehow it was.

I guess I just don't understand the Flashback trojan because no one that I have seen has really described (as the lowest levels) how it works. So, because of this, I am kinda confused how it bypassed the no-executable bit.

From what I gather, plugins like Java (Java has nothing to do with Flash exploits by the way, that's a misleading name it has- along with all the other misleading FUD articles on the 'net like a certain "Ed" likes to troll about) cannot make file operations within the users directories (besides /tmp). Now of course, it can compromise the browsers itself (which can make some file operations in the user its running as- depending on your AA profile) but that doesn't make any sense. Why? Because the Flashback trojan (emphasis on the word Trojan) is browser independent so what this really is, is a phishing scam. That is, unless the plugin itself didn't get sandboxed properly, which is the fault of Mac OSX and not the fault of Java really.

[jerome1232]

True. But in the case of Flashback it was definitely a case of exploiting the system.

Do you have a source, everything I can find about this trojan claims it posed as a legitimate installer for flash. Requiring the user to download and run it and give it sudo permission to then install it's malicious code.

If my information is correct this is a classic case of exploiting... or tricking the user, not exploiting the system. Could happen just as easily with a deb, rpm, or binary on a Linux system.

[rookcifer]

Installers for OSX generally come as disc images, double clicking mounts the disk image which autoruns and will have it's own preset permissions. The user doesn't have to mark anything as executable this way.

Trojans will be trojans, they generally exploit the user not the system.

The later versions of Flashback did not require any user interaction at all. It was a drive-by download. If you visited a site with a browser that had outdated Java, the trojan would somehow download itself and then execute itself. How it does this I do not know. I figured the fact that it didn't have execute rights would stop it, but this doesn't appear to be the case. Again, I am trying to figure out how exactly it bypassed that. None of the blogs out there have explained it.

[Hungry Man]

Flashback has been around for a while. It used to pose as a Flashplayer installer, which required the user to give it permission. Now it exploits the Java vulnerability and does not require permission. If your Java is patched it falls back to its old method ie: tricking the user.

If my information is correct this is a classic case of exploiting... or tricking the user, not exploiting the system. Could happen just as easily with a deb, rpm, or binary on a Linux system.

In the case of the old "social engineering" method, it could happen either way. Just like installing any program. The difference being that Linux users tend to get their packages from "trusted" repositories instead of the internet, and all updates for programs like Flash and Java are handled automatically by the OS. This means that it should, theoretically, be more difficult to trick a user into downloading a fake update/program because they get their programs/ updates through the OS.

[jerome1232]

Thanks, that makes a lot more sense. I guess that's enough derailing the topic.

[rookcifer]

Now it exploits the Java vulnerability and does not require permission. If your Java is patched it falls back to its old method ie: tricking the user.

How does the Java exploit give it permission to execute? It is my understanding that the Java exploit allows the trojan to download to the machine without user interaction. After that this trojan then downloads a malicious payload from a botnet that then executes itself and performs further actions.

So, I guess I am wondering how does it bypass the umask setting of 022? Should it not be impossible for this newly created file to execute? Or does the Java exploit somehow allow it to bypass this?