Are apparmor profiles available for rhythmbox or Totem?

[Hungry Man]

Anything's exploitable. If there is parsing involved a buffer overflow is possible, especially if it's handled using unsafe string methods in C. If it's not validating input properly you could probably heap overflow, depending on how music is played (which I don't know.)

It allows for some kind of input - ie: the music file. That's pretty much all an attacker needs to be able to exploit it, assuming there are vulnerabilities in that area to exploit.

Not sure about that profile. I've never used any music programs on Ubuntu.

[0011235813]

Anything's exploitable. If there is parsing involved a buffer overflow is possible, especially if it's handled using unsafe string methods in C. If it's not validating input properly you could probably heap overflow, depending on how music is played (which I don't know.)

It allows for some kind of input - ie: the music file. That's pretty much all an attacker needs to be able to exploit it, assuming there are vulnerabilities in that area to exploit.

Not sure about that profile. I've never used any music programs on Ubuntu.

Hang on here, I'm getting confused. Anything executable is exploitable, let's clarify this OK? You're talking about C in media files? Uhm... What? Why would there be any executable binaries or scripts in a media file? And if there was a media file (like .wmv) that had some sort of executable code in it, wouldn't ASLR (Address Space Layout Randomization) and DEP (Data Execution Prevention- which is both software and hardware based) prevent buffer overflow (i.e crashing) techniques from being very effective??! I'm a bit confused by what you're trying to say. Does anyone know of any media files that can actually infect Rhythmbox or Banshee?

[Hungry Man]

I'm not saying there are any scripts or binaries in the media file. I'm saying there's data in the media file and the program that interprets it is written in C/C++ (Im' assuming.) What does this mean? You create dynamic buffers on the heap to store data and you're going to probably be parsing quite a lot of things that the user inputs (track data, album art, the media itself.)

You're also misunderstanding what DEP and ASLR do. I'm not trying to argue here. ASLR and DEP don't prevent buffer overflows. I can overflow a buffer with DEP on or off, it doesn't matter. What DEP would stop is the end of that overflow from being executable (hopefully) and ASLR would prevent me from being able to run the code from other areas of the address space without prior knowledge to where those areas are.

Again, you don't need some executable data in the media file.

You have two scenarios:
1) Strcopy the name/album/whatever and overflow it like that. This is easy, bounds checking isn't done in a lot of C string functions so you can drop a double where an int should be and suddenly you've overrun. There can probably be ways around safecopies idk enough about that. Not a hacker. Barely a programmer. There are other unsafe calls like strcopy that'll be easily overflowed though.

2) Heap overflow. Pretty much the same as above, you just need to get the wrong kind of information into the dynamically loaded memory. When a program needs to load up a variable amount of information it creates a pointer array with a variable size. This is pretty safe usually (I would assume. And it has performance benefits) because it can adjust itself to large files. I don't know the details on how someone would overflow on this, I assume if you create an int array (or char or whatever) and drop in a double or float it'll probably be much too large.

What happens after that? Well, if my media file is 100 bytes and the buffer is 4 bytes I now control 96 bytes of information to do with as I please. Did I need executable data in my media file? No. All I needed was the user to click the file and the media player to try to load it up.

DEP and ASLR would, of course, make things much harder from there (they wouldn't prevent the exploit.) I don't think it really makes sense to go into how to bypass those two for the sake of this conversation.

This attack is likely not that practical (it's aimed at a very tiny userbase of people who run a specific program on an OS tha tholds a low percentage, and it's likely that they use safe copies. There are other mitigation techniques implemented that drive up the cost) and you're never going to find it in the wild. You asked for scenarios, so there it is.

[rookcifer]

In any case, the Rhythmbox profile didn't work I got a message error stating there was a missing last line.

Yeah, sorry. I fixed it. The profile posted should now work.

[0011235813]

I'm not saying there are any scripts or binaries in the media file. I'm saying there's data in the media file and the program that interprets it is written in C/C++ (Im' assuming.) What does this mean? You create dynamic buffers on the heap to store data and you're going to probably be parsing quite a lot of things that the user inputs (track data, album art, the media itself.)

You're also misunderstanding what DEP and ASLR do. I'm not trying to argue here. ASLR and DEP don't prevent buffer overflows. I can overflow a buffer with DEP on or off, it doesn't matter. What DEP would stop is the end of that overflow from being executable (hopefully) and ASLR would prevent me from being able to run the code from other areas of the address space without prior knowledge to where those areas are.

Again, you don't need some executable data in the media file.

You have two scenarios:
1) Strcopy the name/album/whatever and overflow it like that. This is easy, bounds checking isn't done in a lot of C string functions so you can drop a double where an int should be and suddenly you've overrun. There can probably be ways around safecopies idk enough about that. Not a hacker. Barely a programmer.

2) Heap overflow with dynamic buffers. Pretty much the same as above, you just need to get the wrong kind of information into there. When a program needs to load up a variable amount of information it creates a pointer array with a variable size. This is pretty safe usually (I would assume. And it has performance benefits) because it can adjust itself to large files. I don't know the details on how someone would overflow on this, I assume if you create an int array (or char or whatever) and drop in a double or float it'll probably be much too large.

What happens after that? Well, if my media file is 100 bytes and the buffer is 4 bytes I now control 96 bytes of information to do with as I please. Did I need executable data in my media file? No. All I needed was the user to click the file and the media player to try to load it up.

DEP and ASLR would, of course, make things much harder from there (they wouldn't prevent the exploit.) I don't think it really makes sense to go into how to bypass those two for the sake of this conversation.

This attack is likely not that practical (it's aimed at a very tiny userbase of people who run a specific program on an OS tha tholds a low percentage, and it's likely that they use safe copies. There are other mitigation techniques implemented that drive up the cost) and you're never going to find it in the wild. You asked for scenarios, so there it is.

I apologise if I didn't make myself clear, I didn't ASLR and DEP would prevent buffer overflows per say, just that it would make it very difficult for a hacker to gain access to the OS if they did try the crash method, so to speak.

What you seem to be saying is that there is a very small chance you might infect something by making a badly packaged media file. What is the point of trying to protect yourself against a threat that is currently only theoretical?

One more question; Linux doesn't give files executable permissions by default, how does one execute a non-executable file? From what I can understand (which is, not a whole lot) a computer file stored on a drive is at the lowest level, a bunch of 0s and 1s (binary- although I suppose it could be single in analogue computers or threes {trinaries?} in future computers) and this includes plain text (which is human readable and is what a compiler uses to make machine executable) and the OS basically just treats them in different ways (a program would make API calls for example). But media files still require another executable to be "displayed" so to speak of. I suppose if the program treated the media files as if it were "executable" (that is, can run calculations in the transistors/cells {in biological computers} of the CPU or GPU[via something like OpenGL]) and can make different data at the end of it (I'm putting it simply here). But media players shouldn't treat media files like executables unless the darn thing requires it (in things like the not-so-venerable ActiveX). Am I getting this right?

[Hungry Man]

All threats are theoretical until they're not. Maybe this will never be exploited and maybe it will be. If I were to bet, I'd bet that it never gets exploited. But setting up an apparmor profile takes all of 5 minutes... so I don't see any issue with a user doing so.

I'm not sure how media programs work. ASLR and DEP don't apply to all programs. EX: Java with a JIT compiler by necessity creates executable code, which means that it's vulnerable to a whole set of other attacks and needs to make use of a whole set of other mitigations. Worth noting since, again, I have close to no idea how th emusic program works.

One more question; Linux doesn't give files executable permissions by default, how does one execute a non-executable file? F

You don't. If my malicious payload is a music file I never execute that file. The user simply double clicks it and what executes is the program (totem? I'll call lit totem.) So I, the hacker, get you to download the music file (or I use an exploit in your browser or plugin to drop it, whatever) and then you the user open the file. The file doesn't need exec permissions. I can open a text file without executing it, right? What executes is "notepad.exe" or gedit or whatever and it's notepad.exe that I'm exploiting.

At no point is the media player "Executing" the file. Even if the file were marked executable it wouldn't matter, there's no code in there. There's no script saying "do X if Y" - it's simply data. Or rather, there's virtually no code. I'll have "datadatadatadata*endofbuffer*code" in my media file. So, it wouuld be like a song with code attached at the end... sorta.

So (in one scenario, the second listed) the music player loads up the media file (in the other it would copy or read data from the file, any data will do such as the artist title etc.) The file is too large and overruns the buffer. What's left is a hanging piece of code (that I'd appended) now in the address space. Without DEP I'm able to do whatever I want with this code, I can execute it right then and there. With DEP I have to jump through a hurdle (not a hard one.)

[0011235813]

All threats are theoretical until they're not. Maybe this will never be exploited and maybe it will be. If I were to bet, I'd bet that it never gets exploited. But setting up an apparmor profile takes all of 5 minutes... so I don't see any issue with a user doing so.

I'm not sure how media programs work. ASLR and DEP don't apply to all programs. EX: Java with a JIT compiler by necessity creates executable code, which means that it's vulnerable to a whole set of other attacks and needs to make use of a whole set of other mitigations. Worth noting since, again, I have close to no idea how th emusic program works.


You don't. If my malicious payload is a music file I never execute that file. The user simply double clicks it and what executes is the program (totem? I'll call lit totem.) So I, the hacker, get you to download the music file (or I use an exploit in your browser or plugin to drop it, whatever) and then you the user open the file. The file doesn't need exec permissions. I can open a text file without executing it, right? What executes is "notepad.exe" or gedit or whatever and it's notepad.exe that I'm exploiting.

At no point is the media player "Executing" the file. Even if the file were marked executable it wouldn't matter, there's no code in there. There's no script saying "do X if Y" - it's simply data. Or rather, there's virtually no code. I'll have "datadatadatadata*endofbuffer*code" in my media file. So, it wouuld be like a song with code attached at the end... sorta.

So (in one scenario, the second listed) the music player loads up the media file (in the other it would copy or read data from the file, any data will do such as the artist title etc.) The file is too large and overruns the buffer. What's left is a hanging piece of code (that I'd appended) now in the address space. Without DEP I'm able to do whatever I want with this code, I can execute it right then and there. With DEP I have to jump through a hurdle (not a hard one.)

I think it all comes down to what is defined by executable. I think that in the strict sense of the word, what you're describing isn't "executable" as such, more like... It *tells* the program to do something that would be considered *malicious* by the programmer/hacker and the user.
But yeah, I think I understand what you're saying.

[Hungry Man]

My media file does not have its own address space, a heap, a stack, libraries, or function calls. That's all I mean. Instead it is a piece of data that is read by a program.

In the end my media file does lead to me executing code though. It's all semantics.

The point I'm trying to get across is that you can take pretty much any kind of program and if it takes some kind of input you can probably exploit that.

[0011235813]

Yeah, sorry. I fixed it. The profile posted should now work.

I'm afraid not. When I turn off rhythmbox, enforce the profile and reload it into the kernel module (following bodhi.zazen's instructions) Rhythmbox refuses to start.

PS: I just thought of a metaphor that would describe the deadly media file virus. Basically, it's like; if I told you to take of your left arm, and you (the media player) did so, that would basically be an infection. So it's not being executed (I'm not making API calls to your neurological brain to cut-of-left-arm) but I'm telling the conscious brain (media player) to do something. Which of course, would require you to be insane (vulnerability within the media player) to happen.

[rookcifer]

You don't. If my malicious payload is a music file I never execute that file. The user simply double clicks it and what executes is the program (totem? I'll call lit totem.) So I, the hacker, get you to download the music file (or I use an exploit in your browser or plugin to drop it, whatever) and then you the user open the file. The file doesn't need exec permissions. I can open a text file without executing it, right? What executes is "notepad.exe" or gedit or whatever and it's notepad.exe that I'm exploiting.

At no point is the media player "Executing" the file. Even if the file were marked executable it wouldn't matter, there's no code in there. There's no script saying "do X if Y" - it's simply data. Or rather, there's virtually no code. I'll have "datadatadatadata*endofbuffer*code" in my media file. So, it wouuld be like a song with code attached at the end... sorta.

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.