Let's try to think through why they might not want to make it completely automatic without several steps. Hmmm. What downside could there possibly be. Let's think. Let's think....
Nope, I can't think of any. Oh wait aren't we're actually responding to a post about a vulnerability in the update mechanism, when you say, "not only is it vulnerable, but it should essentially be automatic!" :)
Basically, if you don't leave your program bit-for-bit the same as it was, maybe you break someone's shitty workflow that you could not possibly have predicted and which has no grounding in anything sane.
3) BIG ONE!!! You might have made a mistake. The old version worked fine, for millions of your customers. But you just pushed a version that causes a fairly common setup to have all sorts of problems.
How do you protect against this? Well, for one thing, you can make the update process a bit more involved. Track it better. Keep logs. Nip it in the bud. (Meaning when the first few complaints from early adopters - who jump through the hurdles - trickle in. Not millions at once.) That way you won't accidentally screw your whole entire installed base for NO reason (what they had was working fine) and cause literally millions of dollars of damage (lost productivity as people, some of whom have no access to any IT, simply cannot see their screens anymore).
4) Maybe your installer is not doing what you think it will do. i.e. vulnerability or error in installer. When you mess remotely on a user's PC, this is not to be taken lightly. At all.
This is actually squarely the territory we're in with this article.
So, I find it kind of funny that in an article on an update vulnerability, someone quips that not only that, but it should be WAY more automatic! :)
Well, I certainly agree that atleast prompting to update is worthwhile, but there are several steps afterwards -- the equivalent of installing a new application -- every time an update comes out.
But that is - MUST be - what you're actually doing: the equivalent of installing a new application. That is the only sane way to do it.
Think of how many errors Windows' aggressive updating causes. And that is from Microsoft. They have ONE JOB! (okay, the OS division has one job).
So if they do all this internal testing and still push things onto your OS that cause problems. What is a third party to do?
The sane thing to do is NOT to treat is as a back door that you can push stuff over, even if the customer asks.
The sane thing to do is to treat it like installing a new application. If the 'new' application has problems, then you stop making it available. You're in control. The customer is in control. It's their pc. It doesn't get broken.
Really, for anything that interacts with the hardware and OS on as low a level as a display driver, there is really no alternative to massive testing beforehand.
Once it's in the wild, you should not expect or have the functionality to simply push firmware or software updates. It should take work and commitment from the customer, the same as installing an application. In the case of firmware, perhaps a bit more.
How does making it multiple steps help the end user? It pops up a dialog recommending you update. As a user, I have zero way to know if the new driver is going to mess everything up. So automatic or not, I'll still be in the same position.
You can at least be conservative by saying "don't touch any software on my machine, I like how it works now".
You can see what bugs were fixed and what features were added and choose to include or not include. At worst you can google and find out how this update affected other users.
This is an (unfortunately) fairly common class of vulnerability. Many applications fall victim to this form of attack because they don't think to check signatures on binaries. There is a tool, EvilGrade (https://code.google.com/p/isr-evilgrade/), designed to assist in demonstrating these types of attacks.
What an idiotic response! Instead of moving to SSL or adding a signature check, they just disable the auto-update and tell you to visit their non-SSL site.
The Graphic Drivers for AMD/ATI were always the main reason why I did buy NVIDIA. As long as I can think back, there have always been problems with those drivers.
I didn't have any of their cards for a decade until I got an old company Dell and hooked it up to the TV. From time to time it forgets that there IS sound coming through the HDMI cable. I googled around. Seems to be a common problem for several versions already. It seemed to have been fixed for some people. Some...
I can't understand how you can allow such things as a big company today.
Update: I take it the automatic update feature was a Windows only thing?
I've had machines using FGLRX off and on for years and never realized it had this feature. Guess that's a good thing, though, considering it evidently was never well implemented. It also seems like bad idea as you might lose compatibility between whichever specific driver/kernel pair if you aren't careful.
But I take exception to those who claim the Catalyst install process is horrendous. I think AMD's process of
and tying in to the DKMS subsystem is much more convenient than Nvidia's approach which directly patches itself into your kernel in a way that would force you to manually reinstall it after every kernel update (unless you were using a distro packaged version, obviously). Maybe they've changed that? (Right now I'm using the distro-packaged driver on my nVidia system.)
While I'm not happy with the current AMD Linux driver mostly because it lacks video decode/render accel as nice as VDPAU, I think most of the other frequent complaints about the driver tend to be a little unfair considering how you can often have obnoxious problems with the nVidia binary as well. With things like HDMI it's been my experience that both drivers tend to have some eccentricities, for example.
19 comments
[ 3.3 ms ] story [ 54.0 ms ] threadNope, I can't think of any. Oh wait aren't we're actually responding to a post about a vulnerability in the update mechanism, when you say, "not only is it vulnerable, but it should essentially be automatic!" :)
1) The customer didn't ask. It's their PC, not yours.
2) "Backwards compatibility." See: https://xkcd.com/1172/
Basically, if you don't leave your program bit-for-bit the same as it was, maybe you break someone's shitty workflow that you could not possibly have predicted and which has no grounding in anything sane.
3) BIG ONE!!! You might have made a mistake. The old version worked fine, for millions of your customers. But you just pushed a version that causes a fairly common setup to have all sorts of problems.
How do you protect against this? Well, for one thing, you can make the update process a bit more involved. Track it better. Keep logs. Nip it in the bud. (Meaning when the first few complaints from early adopters - who jump through the hurdles - trickle in. Not millions at once.) That way you won't accidentally screw your whole entire installed base for NO reason (what they had was working fine) and cause literally millions of dollars of damage (lost productivity as people, some of whom have no access to any IT, simply cannot see their screens anymore).
4) Maybe your installer is not doing what you think it will do. i.e. vulnerability or error in installer. When you mess remotely on a user's PC, this is not to be taken lightly. At all.
This is actually squarely the territory we're in with this article.
So, I find it kind of funny that in an article on an update vulnerability, someone quips that not only that, but it should be WAY more automatic! :)
Think of how many errors Windows' aggressive updating causes. And that is from Microsoft. They have ONE JOB! (okay, the OS division has one job).
So if they do all this internal testing and still push things onto your OS that cause problems. What is a third party to do?
The sane thing to do is NOT to treat is as a back door that you can push stuff over, even if the customer asks.
The sane thing to do is to treat it like installing a new application. If the 'new' application has problems, then you stop making it available. You're in control. The customer is in control. It's their pc. It doesn't get broken.
Really, for anything that interacts with the hardware and OS on as low a level as a display driver, there is really no alternative to massive testing beforehand.
Once it's in the wild, you should not expect or have the functionality to simply push firmware or software updates. It should take work and commitment from the customer, the same as installing an application. In the case of firmware, perhaps a bit more.
You can see what bugs were fixed and what features were added and choose to include or not include. At worst you can google and find out how this update affected other users.
> Due to a minor security vulnerability in the auto-update notification
Palm, meet face.
I didn't have any of their cards for a decade until I got an old company Dell and hooked it up to the TV. From time to time it forgets that there IS sound coming through the HDMI cable. I googled around. Seems to be a common problem for several versions already. It seemed to have been fixed for some people. Some...
I can't understand how you can allow such things as a big company today.
I've had machines using FGLRX off and on for years and never realized it had this feature. Guess that's a good thing, though, considering it evidently was never well implemented. It also seems like bad idea as you might lose compatibility between whichever specific driver/kernel pair if you aren't careful.
But I take exception to those who claim the Catalyst install process is horrendous. I think AMD's process of
./<installerName> --buildpkg <distro/version>
followed by:
<package manager install command (for example, dpkg -i)> <generated package name>
and tying in to the DKMS subsystem is much more convenient than Nvidia's approach which directly patches itself into your kernel in a way that would force you to manually reinstall it after every kernel update (unless you were using a distro packaged version, obviously). Maybe they've changed that? (Right now I'm using the distro-packaged driver on my nVidia system.)
While I'm not happy with the current AMD Linux driver mostly because it lacks video decode/render accel as nice as VDPAU, I think most of the other frequent complaints about the driver tend to be a little unfair considering how you can often have obnoxious problems with the nVidia binary as well. With things like HDMI it's been my experience that both drivers tend to have some eccentricities, for example.