Yeah, I know. It's pretty piss funny that over 200 messages on Slashdot can be posted about this bug in linux kernel drivers, when they're actually in the x11 drivers.
sorry, the majority of people who want a circle tool have long since written The Gimp off, and, in some cases, all open source, after being shouted down by developers. Similar problems exist today with The Gimp, but drawing circles is the canonical example.
People try to use The Gimp to draw circles for the same reason that they use Excel to make lists. Bitmap manipulation and drawing a related activities. You shouldn't have to switch tools to do related activities. The only difference between The Gimp developers and Excel developers is that Excel developers made it easier to perform tasks they hadn't anticipated people would want to do with their software.
Who gives a fuck what they were trying to accomplish? Seriously. The users want to be able to draw circles. They want a circle tool. Some of those users are developers and are quite willing to make a circle tool. The fact that these developers are required to maintain a fork and can't get their tool into the hands of the users who want it is just wrong.
"as good as Photoshop" should not be the standard to which The Gimp is developed. This is the problem with Blender too. Someone complains that doing X is hard in Blender and people reply with "well, it's not like it's easy in 3ds Max either!"
Oh, and stop telling people how to moderate you anonymous nazi fuck. Jesus, you don't even participate in the process and you feel compelled to tell people what to do with their mod points.
But its a fork. If we have to fork The Gimp every time we wanna do something that the current people with power over the source code repository don't like, all we're going to do is fragment the userbase. That divides our community, causes wastage, and disgruntles developers.
Have more than one toolbar, what's hard about that? People who are doing drawing tasks will use the drawing toolbar. People who are not will never see it. The problem here is not that the developers are pig headed. The problem is that they have control over the source code repository and can lock developers who are interested in doing this kind of stuff out of it. If developers were free to add whatever they want to GIMP and push that out to the current GIMP users with everything else, you'd see how many people want these features. But the poltical baggage of forking of project forces developers to tow the line.
Ever tried to do basic drawing in The Gimp? Like, say, drawing a circle? Ask any Gimp developer why this is such a bitch and they'll tell you something like: The Gimp is an image manipulation program, not a drawing program, go use Inkscape or something if you want to draw circles. What's this got to do with Excel? Well, Excel is a spreadsheet program. It's ment for making reports or doing accounting or playing "what if" games with money. About 10 years ago the developers of Excel went and did a survey of what their customers were using Excel for. Turns out the vast majority of people were using Excel to make lists. Shopping lists. Laundry lists. People to Kill. That sort of thing. Did the Excel developers say "hey, Microsoft Word has better support for making lists, go use that!".. no, obviously. What they did was study the way people use the software and make it better for what they are doing. They made it so you could hide the cell lines when you print and so you can print the numbers of the cells if you want. They made it so when you enter something really long into a cell it automatically overlaps the cells next to it, and so it would print that way. That's how software should be made, with a focus on what the user wants out of the software.
Seems kind of harsh to bent all selfrightous over one exploit. I hope nVidia patches it soon.
And that's the problem. The fact that people have been complaining about this for two years, and havn't even put together a binary patch for it, suggests to me that the "we don't have source" argument, although valid, is just an excuse for making yourself a victim. I wish I had heard about this two years ago because I would have made a binary patch and made sure everyone knew they had to install it. But I guess that's what you get when you don't participate in Full Disclosure.
how long have you known that nvidia's linux drivers are unsupported? I should hope you knew about that from day one. They're not obligated (morally or legally) to fix shit in these drivers.
This is a buffer overflow in the closed-source Nvidia X11 driver, not the kernel modules. As far as I'm aware, Nvidia has no binary blobs that get loaded into the Linux kernel. ATI does, but Nvidia doesn't, all their kernel modules are open source.
And for the record, X11 drivers run in userland, as root so they can access hardware ports directly. There's no real reason for them to require root, except that allowing any process to access hardware ports will undermine the security and stability of the system. What you could do is use capabilities to give X11 the ability to access particular hardware ports directly and run it as a regular user instead of root. As long as only root can assign the capabilities you'll be fine.
I gave up trying to get a copy of that Universal AI book.. Asked Amazon for it, paid for the best possible shipping, they still wanted me to wait a month.
This is just the same research that was proposed to prevent black people from enrolling as aviators in WWII. They've just replaced one hated minority with another. If this research was being conducted in California they'd be finding the correlation between smokers and low IQ.
You don't actually know what a trojan is do you? A trojan is a program that you want to run which contains code that does something I want to do. You run it, because you want to, the code does what I want, because I wrote it.
That cleared up, let me explain the sudo vs su thing. If you were do only ever use su, and use it sensibly, I wouldn't have much hope of getting root from a trojan. There are a couple of ways I could.. but they're pretty obvious and you'd most likely spot them. For example, when you next su I could add a parameter to the invokation of su to run a program I've dropped. You enter the root password, my program runs as root, I now have root. This works, but its really easy to detect.. if my program doesn't make a shell for you, you'll immediately notice that I didn't give you a root shell and you'll cry bloody murder. The cheapest way to avoid this is to claim you entered the wrong password even if you didn't.. but that's only really a little bit better because if you are sure you entered the wrong password you'll immediately be suspect and look deeper what happened. A seemingly promising way is to actually run a shell for you. Problem is, the program I dropped and appended to your su command will appear in the process list as the parent process of your shell. Blatantly obvious next time you do a ps.
Hijacking su does have the advantage that you can do it by adding one alias line to the user's.bashrc or.login script. To hijack sudo you need to be a little more creative. By using the ptrace api you can inject code into the user's shell (be that bash, csh, whatever) and intercept every process that is started by it. You don't need any special permissions to use the ptrace api on your own shell. The first time the user does an sudo, you do absolutely nothing. They enter their password, their command happily runs as root, done. Then for a configurable amount of time (timestamp_timeout in/etc/sudoers, defaults to 15 minutes) you can execute sudo as many times as you like and the user will not be prompted for a password. So, by default, for 15 minutes after the user has entered their password for the first time (and yes, it is hard to intercept that password, that at least is well handled) the malicious code running in the user's shell can execute any command it likes with sudo without the user being prompted to enter their password again.
Here we go. You're again smoking the crack pipe. Most the stuff you use might come from people that you trust, but the vast majority of applications in the Ubuntu repository are just packages that people slapped together over the weekend ok? They don't security audit the code. They don't know it is safe. So maybe you're happy to trust them, but I'm not.
All in all, I like to sum it up as such: neither the security model of unix, nor the *cough* security model of Windows were designed for a under-educated user running untrusted applications. These security models are all about multiple users and the educated discretionary granting of permissions between those users. The Windows security model goes a little further than the unix security model in that it has things to say about sharing those permissions over networks, and there are Mandatory Access Control security models that go beyond both of them and say things about permissions that are not at the discretion of the users, but there is no good security model, that I'm aware of, for isolating and controlling the behaviour of the programs which users run in these security models. There have been attempts of course. "Application firewalls".. "capabilities".. but there's no multimillion dollar research going into this like there was put into those other security models. Why? Because all that research was done by the military.. and the military really doesn't have any need to a security model that makes it safe to run arbitary programs because, unlike us consumers, they just don't do that.
The whole point of a trojan is that the user wants to run it. If they want to run it, it doesn't matter how hard it is to run. Even if they have to download and install wine before they can run an exe attachment, they'll do it. Now you might say that is a stupid argument, because no-one is going to write a trojan exe expecting that it might be run on linux under wine and do something useful (to them) in that situation.. but remember that we're supposed to be talking about "targeted trojen attacks" here.. in which case you're more likely to send someone a tar.gz with a linux binary in it asking for help with some problem which that person is capable of solving and likely to provide you help with. A sensible person would run that binary as nobody but because of exactly the attitude that you stressed in your comment:
If something did somehow run the program most likely would not be running with full root (administrative) privileges.
They're likely to run the binary as their regular user account. This, of course, is stupid because, although root is nice to have, it's most likely not the target of the trojan. Those confidential files in your home directory are.
Yes, but compared to getting a trojan into a security fix for Windows it's really easy to get one into Ubuntu, are you so blind that you can't admit that? The whole problem with "trusted sources" is that we shouldn't trust them because they can't provide us with any guarentees beyond "I did my best." We should be running every program with Least Privileged Access, but no-one does that, it's too much trouble. The Gimp shouldn't have access to my Open Office documents. My email program shouldn't have access to write to a.rhosts file in my home directory. That's the kind of security you need to focus on to defeat trojans. Both linux and windows have tools that users can apply to get that kind of security (sudo as nobody, run program as..) but no-one uses them. It's just too much trouble. To make users safer we need to make this stuff automatic and integrated.
none of this relevant to trojans. A trojan is, by definition, something the user wants to run. The fact that most linux users don't run untrusted programs in a "jail" is much the same as the fact that most windows users don't do that either. It's sad, but it's a user education problem, and we're typically not good at solving those. Ubuntu users are encouraged to use "sudo" instead of "su" to run programs as root. sudo allows a permitted user to execute a command as the superuser or another user, but how many people actually use sudo to execute a command as anyone but root? sudo -u nobody./random-email-attachment who does that? no-one.
meh, Ubuntu's use of sudo is worse than the traditional use of su. With su you're required to enter the root password every time whereas, with sudo, you're only required to enter the users password and only once for a given period of time. As such, a program that injects code into the user's shell can easily skip to root. I know, I've written code to do it. That's without taking advantage of any suid binaries or services running as root or kernel bugs to get root. Getting root from a trojan running on a user account is not hard. Besides which, who gives a shit about root? A trojan doesn't need root to copy confidential data from a user's home directory. It doesn't need root to open a socket and send that information back home. It doesn't need root to modify or delete important files. It doesn't need root to hijack mail programs and send emails as the targetted user. This obsession with root by people who think they understand security is troubling.
Back to what I was saying about Ubuntu's repositories. It often occurs that maintainers put unsigned packages in them. It's a common complaint. Go ask them if you don't believe me. People should refuse to install these packages, as the signatures give at least some level of assurance that what you're installing is what the maintainer produced and hasn't been interfered with in transit. Of course, I say some level of assurance because there's nothing to stop an attacker from interfering with binaries (or even source) going to a maintainer who then goes and happily signs it thereby declaring to the world that it is safe. Think about it. That's what package maintainers are for.. taking stuff that isn't packaged, packing it up, signing it and puting it in a repository for users to download and run. Maybe the very first time a maintainer checks the source for a program out of the source code repository for that project they'll do a thorough analysis to ensure they are not signing their name to some piece of malware, but do you really think they do that same analysis every time they update from the repository? Of course they don't. They grab the latest source, check the bug trackers to see what state it is in. Maybe talk to the developers about what they intend on doing in future releases, then they add the Ubuntu specific patches, compile it, package it, sign it and ship it. Their connection to the source code repository could well have been compromised for all they know.. they're not going to check every line of code, and they might not notice something like a subtle security bug that has been introduced anyways.
And it's not like these people are hard to find.. it's public knowledge who maintains which packages. You're absolutely right that it is easier to get a chump to run an arbitary exe on windows - just fake mail them an attachment and say "this is so funny" and they'll run it. But how much harder is it to get thousands and thousands of people to run a trojan on linux than it is on windows? How much harder is it to get the entire install base to run a trojan? Using the techniques above (and maybe some more involving actual viruses) at the appropriate time, I'm sure I could get a trojan into some "critical security fix" that ubuntu-security is pushing out to every user of ubuntu. Doing the same for some Windows hot fix or some other big install base would be much harder.. there's just not the same opportunities to intercept and insert code.
Slashdot Mirror
no, you need to get out and realise that all proprietary software is insecure. period.
Yeah, I know. It's pretty piss funny that over 200 messages on Slashdot can be posted about this bug in linux kernel drivers, when they're actually in the x11 drivers.
sorry, the majority of people who want a circle tool have long since written The Gimp off, and, in some cases, all open source, after being shouted down by developers. Similar problems exist today with The Gimp, but drawing circles is the canonical example.
People try to use The Gimp to draw circles for the same reason that they use Excel to make lists. Bitmap manipulation and drawing a related activities. You shouldn't have to switch tools to do related activities. The only difference between The Gimp developers and Excel developers is that Excel developers made it easier to perform tasks they hadn't anticipated people would want to do with their software.
Who gives a fuck what they were trying to accomplish? Seriously. The users want to be able to draw circles. They want a circle tool. Some of those users are developers and are quite willing to make a circle tool. The fact that these developers are required to maintain a fork and can't get their tool into the hands of the users who want it is just wrong.
"as good as Photoshop" should not be the standard to which The Gimp is developed. This is the problem with Blender too. Someone complains that doing X is hard in Blender and people reply with "well, it's not like it's easy in 3ds Max either!"
Oh, and stop telling people how to moderate you anonymous nazi fuck. Jesus, you don't even participate in the process and you feel compelled to tell people what to do with their mod points.
Bah. Inkscape is not a better piece of software for bitmap manipulation.
But its a fork. If we have to fork The Gimp every time we wanna do something that the current people with power over the source code repository don't like, all we're going to do is fragment the userbase. That divides our community, causes wastage, and disgruntles developers.
Have more than one toolbar, what's hard about that? People who are doing drawing tasks will use the drawing toolbar. People who are not will never see it. The problem here is not that the developers are pig headed. The problem is that they have control over the source code repository and can lock developers who are interested in doing this kind of stuff out of it. If developers were free to add whatever they want to GIMP and push that out to the current GIMP users with everything else, you'd see how many people want these features. But the poltical baggage of forking of project forces developers to tow the line.
Yeah, like Blender has improved.. oh wait.
Ever tried to do basic drawing in The Gimp? Like, say, drawing a circle? Ask any Gimp developer why this is such a bitch and they'll tell you something like: The Gimp is an image manipulation program, not a drawing program, go use Inkscape or something if you want to draw circles. What's this got to do with Excel? Well, Excel is a spreadsheet program. It's ment for making reports or doing accounting or playing "what if" games with money. About 10 years ago the developers of Excel went and did a survey of what their customers were using Excel for. Turns out the vast majority of people were using Excel to make lists. Shopping lists. Laundry lists. People to Kill. That sort of thing. Did the Excel developers say "hey, Microsoft Word has better support for making lists, go use that!" .. no, obviously. What they did was study the way people use the software and make it better for what they are doing. They made it so you could hide the cell lines when you print and so you can print the numbers of the cells if you want. They made it so when you enter something really long into a cell it automatically overlaps the cells next to it, and so it would print that way. That's how software should be made, with a focus on what the user wants out of the software.
Seems kind of harsh to bent all selfrightous over one exploit. I hope nVidia patches it soon.
And that's the problem. The fact that people have been complaining about this for two years, and havn't even put together a binary patch for it, suggests to me that the "we don't have source" argument, although valid, is just an excuse for making yourself a victim. I wish I had heard about this two years ago because I would have made a binary patch and made sure everyone knew they had to install it. But I guess that's what you get when you don't participate in Full Disclosure.
Personally, I'd prefer "Root Exploit found for Nvidia's X11 driver".
how long have you known that nvidia's linux drivers are unsupported? I should hope you knew about that from day one. They're not obligated (morally or legally) to fix shit in these drivers.
This is a buffer overflow in the closed-source Nvidia X11 driver, not the kernel modules. As far as I'm aware, Nvidia has no binary blobs that get loaded into the Linux kernel. ATI does, but Nvidia doesn't, all their kernel modules are open source.
And for the record, X11 drivers run in userland, as root so they can access hardware ports directly. There's no real reason for them to require root, except that allowing any process to access hardware ports will undermine the security and stability of the system. What you could do is use capabilities to give X11 the ability to access particular hardware ports directly and run it as a regular user instead of root. As long as only root can assign the capabilities you'll be fine.
if you used closed source drivers on a machine that you need to be secure, you're a dickhead.
I gave up trying to get a copy of that Universal AI book.. Asked Amazon for it, paid for the best possible shipping, they still wanted me to wait a month.
This is just the same research that was proposed to prevent black people from enrolling as aviators in WWII. They've just replaced one hated minority with another. If this research was being conducted in California they'd be finding the correlation between smokers and low IQ.
You don't actually know what a trojan is do you? A trojan is a program that you want to run which contains code that does something I want to do. You run it, because you want to, the code does what I want, because I wrote it.
.bashrc or .login script. To hijack sudo you need to be a little more creative. By using the ptrace api you can inject code into the user's shell (be that bash, csh, whatever) and intercept every process that is started by it. You don't need any special permissions to use the ptrace api on your own shell. The first time the user does an sudo, you do absolutely nothing. They enter their password, their command happily runs as root, done. Then for a configurable amount of time (timestamp_timeout in /etc/sudoers, defaults to 15 minutes) you can execute sudo as many times as you like and the user will not be prompted for a password. So, by default, for 15 minutes after the user has entered their password for the first time (and yes, it is hard to intercept that password, that at least is well handled) the malicious code running in the user's shell can execute any command it likes with sudo without the user being prompted to enter their password again.
That cleared up, let me explain the sudo vs su thing. If you were do only ever use su, and use it sensibly, I wouldn't have much hope of getting root from a trojan. There are a couple of ways I could.. but they're pretty obvious and you'd most likely spot them. For example, when you next su I could add a parameter to the invokation of su to run a program I've dropped. You enter the root password, my program runs as root, I now have root. This works, but its really easy to detect.. if my program doesn't make a shell for you, you'll immediately notice that I didn't give you a root shell and you'll cry bloody murder. The cheapest way to avoid this is to claim you entered the wrong password even if you didn't.. but that's only really a little bit better because if you are sure you entered the wrong password you'll immediately be suspect and look deeper what happened. A seemingly promising way is to actually run a shell for you. Problem is, the program I dropped and appended to your su command will appear in the process list as the parent process of your shell. Blatantly obvious next time you do a ps.
Hijacking su does have the advantage that you can do it by adding one alias line to the user's
Here we go. You're again smoking the crack pipe. Most the stuff you use might come from people that you trust, but the vast majority of applications in the Ubuntu repository are just packages that people slapped together over the weekend ok? They don't security audit the code. They don't know it is safe. So maybe you're happy to trust them, but I'm not.
All in all, I like to sum it up as such: neither the security model of unix, nor the *cough* security model of Windows were designed for a under-educated user running untrusted applications. These security models are all about multiple users and the educated discretionary granting of permissions between those users. The Windows security model goes a little further than the unix security model in that it has things to say about sharing those permissions over networks, and there are Mandatory Access Control security models that go beyond both of them and say things about permissions that are not at the discretion of the users, but there is no good security model, that I'm aware of, for isolating and controlling the behaviour of the programs which users run in these security models. There have been attempts of course. "Application firewalls".. "capabilities".. but there's no multimillion dollar research going into this like there was put into those other security models. Why? Because all that research was done by the military.. and the military really doesn't have any need to a security model that makes it safe to run arbitary programs because, unlike us consumers, they just don't do that.
The whole point of a trojan is that the user wants to run it. If they want to run it, it doesn't matter how hard it is to run. Even if they have to download and install wine before they can run an exe attachment, they'll do it. Now you might say that is a stupid argument, because no-one is going to write a trojan exe expecting that it might be run on linux under wine and do something useful (to them) in that situation.. but remember that we're supposed to be talking about "targeted trojen attacks" here.. in which case you're more likely to send someone a tar.gz with a linux binary in it asking for help with some problem which that person is capable of solving and likely to provide you help with. A sensible person would run that binary as nobody but because of exactly the attitude that you stressed in your comment:
If something did somehow run the program most likely would not be running with full root (administrative) privileges.
They're likely to run the binary as their regular user account. This, of course, is stupid because, although root is nice to have, it's most likely not the target of the trojan. Those confidential files in your home directory are.
Yes, but compared to getting a trojan into a security fix for Windows it's really easy to get one into Ubuntu, are you so blind that you can't admit that? The whole problem with "trusted sources" is that we shouldn't trust them because they can't provide us with any guarentees beyond "I did my best." We should be running every program with Least Privileged Access, but no-one does that, it's too much trouble. The Gimp shouldn't have access to my Open Office documents. My email program shouldn't have access to write to a .rhosts file in my home directory. That's the kind of security you need to focus on to defeat trojans. Both linux and windows have tools that users can apply to get that kind of security (sudo as nobody, run program as..) but no-one uses them. It's just too much trouble. To make users safer we need to make this stuff automatic and integrated.
none of this relevant to trojans. A trojan is, by definition, something the user wants to run. The fact that most linux users don't run untrusted programs in a "jail" is much the same as the fact that most windows users don't do that either. It's sad, but it's a user education problem, and we're typically not good at solving those. Ubuntu users are encouraged to use "sudo" instead of "su" to run programs as root. sudo allows a permitted user to execute a command as the superuser or another user, but how many people actually use sudo to execute a command as anyone but root? sudo -u nobody ./random-email-attachment who does that? no-one.
meh, Ubuntu's use of sudo is worse than the traditional use of su. With su you're required to enter the root password every time whereas, with sudo, you're only required to enter the users password and only once for a given period of time. As such, a program that injects code into the user's shell can easily skip to root. I know, I've written code to do it. That's without taking advantage of any suid binaries or services running as root or kernel bugs to get root. Getting root from a trojan running on a user account is not hard. Besides which, who gives a shit about root? A trojan doesn't need root to copy confidential data from a user's home directory. It doesn't need root to open a socket and send that information back home. It doesn't need root to modify or delete important files. It doesn't need root to hijack mail programs and send emails as the targetted user. This obsession with root by people who think they understand security is troubling.
Back to what I was saying about Ubuntu's repositories. It often occurs that maintainers put unsigned packages in them. It's a common complaint. Go ask them if you don't believe me. People should refuse to install these packages, as the signatures give at least some level of assurance that what you're installing is what the maintainer produced and hasn't been interfered with in transit. Of course, I say some level of assurance because there's nothing to stop an attacker from interfering with binaries (or even source) going to a maintainer who then goes and happily signs it thereby declaring to the world that it is safe. Think about it. That's what package maintainers are for.. taking stuff that isn't packaged, packing it up, signing it and puting it in a repository for users to download and run. Maybe the very first time a maintainer checks the source for a program out of the source code repository for that project they'll do a thorough analysis to ensure they are not signing their name to some piece of malware, but do you really think they do that same analysis every time they update from the repository? Of course they don't. They grab the latest source, check the bug trackers to see what state it is in. Maybe talk to the developers about what they intend on doing in future releases, then they add the Ubuntu specific patches, compile it, package it, sign it and ship it. Their connection to the source code repository could well have been compromised for all they know.. they're not going to check every line of code, and they might not notice something like a subtle security bug that has been introduced anyways.
And it's not like these people are hard to find.. it's public knowledge who maintains which packages. You're absolutely right that it is easier to get a chump to run an arbitary exe on windows - just fake mail them an attachment and say "this is so funny" and they'll run it. But how much harder is it to get thousands and thousands of people to run a trojan on linux than it is on windows? How much harder is it to get the entire install base to run a trojan? Using the techniques above (and maybe some more involving actual viruses) at the appropriate time, I'm sure I could get a trojan into some "critical security fix" that ubuntu-security is pushing out to every user of ubuntu. Doing the same for some Windows hot fix or some other big install base would be much harder.. there's just not the same opportunities to intercept and insert code.