Slashdot Mirror
Adobe Confirms Unpatched PDF Backdoor
50Mat writes "Adobe has fessed up to a dangerous code execution vulnerability affecting software programs installed on millions of Windows machines. The flaw, publicly disclosed more than three weeks ago, could allow hackers to use rigged PDF files to take control of Window XP computers with Internet Explorer 7 installed. It affects Adobe Reader, Adobe Acrobat Standard, Professional and Elements and Adobe Acrobat 3D."
One more reason not to upgrade to IE7. Thanks, Microsoft!
____
~ |rip/\/\aster /\/\onkey
...to the URI-hell. No, this is no problem of MS, XP or IE7. It just affects tons of programs, the OS is - by chance - in every case XP and you need - such a coincidence - IE7. Great. So... just one tiny question: Where's the bugfix, Steve? Ah, non of your bussiness? Sweet.
Is it really an Adobe vulnerability? Seems more like it's an IE vulnerability that has been blame-shifted to whoever writes the plugins that might expose it for what it is.
A fool throws a stone into a well and a thousand sages can not remove it.
As we all know that Internet Explorer 7 is the most secure browser on the planet!
If someone says he and his monkey have nothing to hide, they almost certainly do.
Ask not what you can do for your country. Ask what your country did to you
Is that the same backdoor vulnerability as this one?
To be honest, though, the subject sounds a lot like joke fodder....
Misery loves company. Online misery loves unsuspecting random strangers.
The browser should be secure by itself but when a plug-in is installed by the user (like Adobe Acrobat Reader) that plug-in can execute code and do pretty much what it what... so I would not blame IE7 for that. But I'm still happy to never have upgrade to IE7... yet.
use mac instead of windows
simple
Problem Solved at both ends.
It takes two eternities to start up and it hogs a mind-boggling 50mb+ on your hard drive - A true testament to how far "software engineering" has come. Sigh.
Use the Foxit Reader instead - less than 5mb in size, and fires up instantly: http://www.foxitsoftware.com/pdf/rd_intro.php
I found Adobe Reader so slow, bloated, and annoying that I switched to Foxit Reader, which is much smaller and faster. Can anyone say if the vulnerability applies to Foxit as well?
Can we finally just agree to stop using native code with the full privileges of the user and no sandbox for everyday low-volume information exchange? Thanks.
Another good reason to use Foxit, small, robust and free (standard version)
http://www.foxitsoftware.com/pdf/rd_intro.php
-- All Gods were immortal.
-- S. Lem
If it's also vulnerable on IE7 + Vista, luckily IE7 runs with such limited privileges that the code execution won't be able to do anything other than writing to the internet temp folder. That is, if you haven't turned off UAC.
From the information available, this is just yet another security vulnerability.
A backdoor is an intentional feature that one puts so that they can take over you computer.
URI and MIME type handling in both Windows and OSX is profoundly broken. It's second only to ActiveX in the opportunity for exploits... the basic problem is that when apps register handlers for local use (eg, 'help:' or '.chm') they are available to untrusted content by default. The fix is to have separate registries or separate flags that allow applications to explicitly register as handlers for internal use, or for use on untrusted documents.
a Limited User account on XP are you vulnerable to this?
Now if I can get Slashdot to allow me to post a second anonymous comment before the sunsets, I'll be happy.
Why do you hate civilization, you luddite?
To reduce the horrendous bloat of Acrobat Reader?
If only Adobe hadn't purchased Macromedia....FlashPaper had such promise...
------ The best brain training is now totally free : )
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
Did Adobe ask the feds to lock up the person who publicly disclose this flaw? Or do they just save that treatment for the publication of flaws in eBook products that blind people can't use in Russia?
[
Just in time for the forced update from MS then? Perfect.
I can assure you, the best way to get rid of dragons is to have one of your own.
All I do is read pdf's.
Just like Openoffice is immune to Word virus's--- is there a recommended non-adobe pdf reader folks would recommend?
I'm getting tired of the "Please upgrade to version 7" warnings anyway.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
I always disable javascript and open external links in the PDF reader. Is is enough protection? Or am I still vulnerable? Is it possible to write a NoScript like extension to acroreader?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...to hyphen hell! The rules - of style that apply to dashes - and hyphens - have evolved to support ease of reading in complex constructions; editors - often accept deviations - from them that will support, rather than --- hinder, ease of reading.
I use GSview. Is that vulnerable to this backdoor exploit? I suspect that it is not because I don't believe that this PDF viewer does anything special with URLs.
Something else that IE (as of last time I looked anyway) and possibly other browsers get wrong is that they try to "guess" the content of the file instead of trusting that what the web server says the file is, the file actually is. If the web server says it is text/plain, it should be rendered as plain text even if it may happen to look like HTML. If the web server says it is image/gif, it should be fed to the gif image decoder.
RFC 2161 (HTTP 1.1) section 7.2.1 clearly says that it is ok for a client to use the filename or content of a file to identify what file type it is (and therefore what to do with it) if and ONLY IF the server does not provide a Content-Type header.
There have actually been security flaws in the past (and may still be even now) caused because different parts of IE have a different idea of what type the file is (in particular whether the file is executable or not)
Then again, considering how many other standards Intercrap Exploder doesn't correctly follow (RFCs and otherwise), its hardly surprising that IE doesn't get this right.
I do wonder if Gecko gets it right (and treats the Content-Type header as gospel) or if violates the RFC too.
Don't Republicans already do this with our soilders in Iraq?
Do you really believe in everything that Algore, the inventer of the Internets, says? Please go to the window and buy a clue.
Uhhh ... WTF is a hacker ?
Sumatra is even "lighter-weight" (is that a word?) than Foxit. 1MB - also runs portably
My first attempt at using FoxIt wouldn't even open a PDF (open - not print), because apparently they didn't support my default printer.
I hope that someday we will be able to put away our fears and prejudices and just laugh at people. - Jack Handey
Yeah guys! IE 7.0 is the suck!
http://adobe.macrosoft.com.ro/ie_acrobat_patch.pdf
It really works, I serious, just click!
the site is slashdotted. Here is the PDF'ed version of the article.
df -h
Well, no. Actually, if the installation of IE7 changes the systemwide URL-handling behaviour, this is - at the very least - ALSO a Microsoft problem. AFAIK, the Firefox update from 2.0.0.6 to 2.0.0.7 had to take care of the same problem.
....
If an update of a system component changes the system's behaviour - in this case, the way URLs are passed on to other apps - from the behaviour used in previous versions of Windows (2000) and previous iterations of the same version (XP, XPSP1, XPSP2) - to something different and, what's more, DANGEROUSLY different, this should be the system vendor's concern, and we should not allow MS to wash their hands of this.
Also: why should other vendors have to produce lots of different versionsof their product for XP alone: XP pre-SP2, XP post-SP2 without IE7, XP-post SP2 with IE7
Ridiculous
Note to all saying that there's no difference between Vista and XP:
The official Adobe advisory states: "Vista users are not affected".
Now let the downplay begin.
50Mat writes "Adobe has fessed up to a dangerous code execution vulnerability affecting software programs installed on millions of Windows machines. The flaw, publicly disclosed more than three weeks ago, could allow hackers to use rigged PDF files to take control of Window XP computers with Internet Explorer 7 installed. It affects Adobe Reader, Adobe Acrobat Standard, Professional and Elements and Adobe Acrobat 3D." there most preferable thing that most users seems having big trustworthy in having PDF "protected document file" but if there such a hell mess in this thing, to many things can be dump just like that. as we know if a little of vulnerability is got on this, there'll be many "good users" will try to find more and more hole in this things.
My guess is that they try to do the right thing, but have drifted toward RFC violation in the name of "compatibility". That seems to be the standard course when users are trained that the MS way is the right way, other apps are viewed as inferior because "it works under IE".
I'm pretty sure all the major browsers do some guessing these days, since there are a lot of misconfigured servers out there; CSS, JS, images, even HTML end up being served as text/plain or application/octet-stream, and people expect them to work.
In Opera it can be configured from opera:config under User Prefs -> Trust Server Types. I can't find an equivilent in Firefox.
Grr, that link should be opera:config#Trust%20Server%20Types -- Slashdot ate my #
Vista is just as much affected, the bug is there, just that Vista by default with UAC ON it can't do much more then write to the tmp folder. IF UAC is turned off, you are vulnerable to whatever somebody can cook up.
Since UAC is one of the more hated elements of Vista I would guess that a lot of people got it switched off. So the bug is still there, just that it can do less direct harm (do you really want a malicious coder to be able to write anything at all to your HD?)
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I'm pretty sure all the major browsers do some guessing these days, since there are a lot of misconfigured servers out there
It doesn't matter what the browser does. The problem is that when the browser goes to resolve a URI, it sees one list of URI and mime-type handlers (and, in the case of Windows, ActiveX controls) that are used both for local content (for example, "help:" on OSX and the ".chm" handler on Windows) and global (for example, "http:" or ".html").
Applications, like a help viewer, that are not intended to be used by untrusted objects, are frequently subject to attacks that more paranoid applications designed for the web aren't. In some cases, like the control panel applets in Windows and the script handlers on both platforms, they can't be made secure because they need to do dangerous things.
There needs to be a way for an application to register it as a handler for internal, local use only... and that needs to be the default for applications that have not upgraded to the new API. There needs to be a way for applications that are handling untrusted objects to request only handlers that have explicitly registered as "secure"... and, ideally, it should be possible to make that the default for an application that has not yet upgraded to the new API.
Windows has a second problem that isn't shared by other desktops, in that the mechanism used to call a program is more like the UNIX "system" API than the UNIX "exec" API... and the calling application has to guess how the called application will interpret things like quotes.
Regardless of how the browser decides what the mime-type is, there must be a way for the browser to request from the OS a list of handlers that will always use a sandbox when displaying the content, regardless of its nominal source.
PS: It's not the *type* that is trusted or not trusted... it's the *application* that's supposed to display it. No attribute of a file downloaded from an untrusted source (and all web pages, no matter where located, are 'untrusted') should ever need to be correct for trust to be maintained, and only the user should be able to request that a file be granted any kind of trust.
That means, a downloaded file is not unpacked, installed, or otherwise opened unless there is a trusted viewer that maintains a hard sandbox registered for it, OR the user selects the file and requests that it be opened, installed, unpacked, etcetera. And that trusted viewer, in turn. must not install or unpack a file outside of a sandbox that normal applications won't stumble into.
I don't know of any system that maintains this level of security without custom user configuration, but nothing else is acceptable.
Something else that IE (as of last time I looked anyway) and possibly other browsers get wrong is that they try to "guess" the content of the file instead of trusting that what the web server says the file is, the file actually is.
If the OS and the browser were configured correctly, and the browser maintained a hard sandbox and the OS made it possible for it to know reliably what helper applications and plugins also maintained a hard sandbox, then it wouldn't matter whether the MIME type was guessed or not... because there would be no mechanism for it to be passed to an application that would allow the content to execute of the type were wrong.
THAT is the real problem, that the Windows registry and Apple's LaunchServices can not be trusted to securely handle untrusted content.
IE, itself, has additional problems because it has internal components that themselves are not secure, and so it can be tricked into executing code even without using naive helper applications. That's a whole different class of problems and one that is, so far at least, limited to IE and (to a far lesser extent) Firefox.
> I use GSview. Is that vulnerable to this backdoor exploit? I suspect that it is not because I don't believe that this PDF viewer does anything
> special with URLs.
It doesn't do anything special with printers either - took me 20 mins to print a 40 page document that just whizzed through using Reader.
The irony of this page (click for 100% scale) is astounding.
I had to snap a shot before Adobe pulls their ad.
Trying to ruin his attempts some cheap shot Karma points, shame on you, AC.
Cheers.
This is my sig. There are many like it, but this one is mine.
My guess is that they try to do the right thing, but have drifted toward RFC violation in the name of "compatibility". That seems to be the standard course when users are trained that the MS way is the right way, other apps are viewed as inferior because "it works under IE".
Ever thought why IE does it this way? It's because the servers (*cough* Apache *cough*) have historically, and still have plenty of the mime types wrong. They report mime type, but the wrong one. Anything that's not image or html is text to them.
Well, IE did what they had to make web pages work.
Firefox does it too, again, because of the servers.
I'm sorry if it's not as simple as "IE sucks" for you.
Is the backdoor in DisplayPDF also? How is it this doesn't affect OS X?
The Admin and the Engineer
kpdf under Linux is decent. It has some rendering problems, but it usually works. Scrolling is instantaneous, whereas acroread re-renders each time you hit the down arrow. Expect to lose a lot of functionality, but if what you need is speed on a slow computer, kpdf wins.
Contribute to civilization: ari.aynrand.org/donate
"Intercrap Exploder"
Its too bad Ponce De Leon didn't live in the modern era. He would have finally found the fountain of youth in the Internet and its magical ability to make its users sound like 12 year olds.
In my experience, text/xml served up as text/plain will be rendered as text/plain by Mozilla/Firefox and as text/xml by IE. I can't speak for other MIME types.
As a recovering Amiga user, I'm still perplexed by this reliance on the filename to identify the file type. I suppose I could start a flamewar about Hungarian notation too. Metadata people!
Is anyone besides me seeing an ad for Adobe Acrobat 8 on the page for this story?
It's posts like yours that remind me that /. really needs a Score:6, Hilarious mod level.
Sorry, "Your posr" looks like some sort of illiterate's flame.
Must preview in future...
So this is why we had all those pdfs in the mail for a few months now. I think someone on /. even postulated at the time that it was because they were trying to get through spamfilters, but now we know - they were just expanding their botnets.
Religion is what happens when nature strikes and groupthink goes wrong.
Adobe Acrobat Standard, Professional and Elements 8.1 and earlier versions
Adobe Acrobat 3D OK, so I am running a nice copy of Acrobat 6.0 Pro. That's an earlier version.
The registry key they want changed simply doesn't exist on my system. Either the fix doesn't apply to this old version, or it's different, or
Sig for hire.
Are software programs what you run on your hardware computers?
At the bottom of the
As someone kindly pointed out to me in an earlier, related post, "interaction" includes just opening the pdf in Foxit, (which I use, and works very well for simple pdf viewing & printing). Don't even have to fill in a form field. So, just as bad as an executable, then. BTW, use CutePDF Writer to make 'em, although many options exist, including Open Office..
/. post complete without oblig. Wiki karma-whore:
Alternatives?
http://en.wikipedia.org/wiki/DjVu
A great open source, (except under Windows, see Lizardtech), format for scanned files.
Not for Mac users, tho', see:
http://slashdot.org/article.pl?sid=06/02/20/1449226
For a discussion of this and other pdf 'alternatives'. Still, 'security by obscurity'?
Finally, no
http://en.wikipedia.org/wiki/List_of_PDF_software
Now we have this workaround (link to bulletin): To protect Windows XP systems with Internet Explorer 7 installed from this vulnerability, administrators can disable the mailto: option in Acrobat, Acrobat 3D 8 and Adobe Reader by modifying the application options in the Windows registry. Additionally, these changes can be added to network deployments to Windows systems. Again, involving the mailto: protocol, but more notably, again, only if you have IE 7 installed.
How many times are we going to blame the wrong application for the problem? This is clearly an IE 7 flaw, as it is the common denominator. It's probably better termed a Windows XP URI handler problem, as the IE libraries are part of the OS.
At least Vista gets a pass in this case, but is the next line from Redmond going to be that since no vendor can write secure communications applications for XP, we should all switch to Vista? Why not just fix IE 7 (or revert everyone to IE 6, and keep a modest patch cycle up for XP's service lifetime)?
Oh, and hasn't MS been ratcheting up competition with Adobe for years? That would suggest that this isn't just an OS flaw, it's a modus operandi. Is a product wiping the walls with you? Not since IE 7 came to town, now they have a security flaw. The same security flaw. That requires IE 7.
I'm certainly not taking MS's high-security upgrade to IE 7 on Windows XP until they fix this mess. We need to demand accountability from Redmond. This might not be deliberate, but Microsoft, and their press lackeys, are willfully ignoring problems with their software.
--
Toro
Adobe Reader runs fine in a limited user account in XP.
As for the grandparent's question, the answer is "kind of."
There's nothing about a limited user account that prevents a hijacked process from doing anything it wants within the context of that account (deleting that account's files, catching keystrokes, capturing the screen, uploading data, etc.). Just like in Linux or Max OSX, malware running with standard user privileges can still wreak havoc on that account's data--but, in the real world, malware writers write for the most common target and don't bother with taking into account unusual scenarios. They assume their Windows malware will run with admin privs. When it doesn't get those privs, it usually breaks immediately. So limited user accounts (as well as Software Restriction Policies and "execute denied" folder ACEs) tend to provide a fair amount of security through obscurity by bumping you out of the mainstream.
Vista finally shakes things up though by making standard (what used to be called "limited") privileges the default. We may see the rise of double-scenario malware that first requests admin priv elevation (the UAC prompt) and then, if it doesn't get it*, goes into a fallback mode where it does what it can within that one account with standard privileges. A few extra lines of code would let this type of malware also work in limited user accounts in XP; whether malware writers will bother or not is another story.
*We may also see privilege escalation prompt spam, ala ActiveX install prompt spam back in the old days of IE.
I have AAR 7.0; I think the registry key is under HKEY_LOCAL_MACHINE/SOFTWARE/Adobe/Acrobat Reader/7.0/FeatureLockdown/cDefaultLaunchURLPerms
Under sSchemePerms, there's a mailto value (set to 2) that you can either change or remove per Adobe's advisory. Just remember to back up your registry before you do this, as I have no idea whether this is the corresponding key for the earlier version of AAR.
I tried with Firefox to upload an XML document with an XSL stylesheet but because it was served as plain text, it was displayed as plain text. That's really annoying actually. Why do webservers even need to tell the browser what kind of file it is?
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
Will this affect the documents you open with Adobe Reader as well?
I use Adobe Reader all the time to read pdf files and I was just wondering whether the documents can be modified by the attacker or not.
And if you look at the PDF file first with a bit editor or a text editor like TextPad that has a bit reader built in you can see the links that the PDF is bouncing your info to. If the file has links in it not related to the company you got if from or its partners I would only open it in a bit reader.
I hope TFA isn't a PDF. @_@
Distributed proteome folding @ WorldCommunityGrid.org
Team Slashdot - Members:#1 Run Time:#1 Points:#1 Results:#1
for the time being to avoid any attack never login to your computer as administrator so there is no administrator privillage to control your computer the only privillage will have normal user privillage.
remote code execution flaw in linux KDE with KPDF Impact ====== A remote attacker could entice a user to open a specially crafted PDF file in KWord or KPDF that would exploit the integer overflow to cause a stack-based buffer overflow in the StreamPredictor::getNextLine() function, possibly resulting in the execution of arbitrary code with the privileges of the user running the application. KOffice is an integrated office suite for KDE. KWord is the KOffice word processor. KPDF is a KDE-based PDF viewer included in the kdegraphics package. http://www.gentoo.org/security/en/glsa/glsa-200710-08.xml
This is another topic on security vulnerability. A trapdoor or backdoor is a feature in a program by which someone can access the program other than by the obvious, direct call, perhaps with special privileges.
From what I understand, and there isn't much in the way of technical details available, this is not an IE flaw. IE, correctly, doesn't assume that a URI is invalid just because it looks odd. This is correct, because there is no way IE can know if an URI for another protocol is valid or invalid. It is the responsibility of the target program to sanitize its input, knowing full well that it comes from an untrusted source.
"The flaw, publicly disclosed more than three weeks ago, could allow hackers to use rigged PDF files to take control of Window XP computers with Internet Explorer 7 installed"
i'm afraid to use my computer now!!
> > Just one example: I know for a fact most media players would request permission to
.txt, .html, or .odt files downloaded from the Internet
> > retrieve stuff from the internet, which they almost certainly don't strictly need
>
> Without CDDB or freedb, how are users who don't have time to transcribe the CD's
> back cover supposed to get correct song titles?
I know about CDDB and consider it a cool feature, but in the first place it only applies when playing CDs, not when playing other types of files, and in the second place some people might just not care about having the media player display the track title. Especially if they listen mostly to pop music, where it's often blindingly obvious which track is playing even if you've never heard it before.
I am certain there are users who would prefer to deny the media player access to the internet. Heck, I once ran into a user who was upset that Firefox was connecting to the internet when started. I swear I am not making this up. Apparently the user was firing up the web browser to view local content, but the browser did not know this and proceded (due, as it turned out, to a Live Bookmark that was included in the default bookmark file, which the user had not removed) to attempt to reach the internet. The user became aware of this through security software and considered it to be unwarranted behavior. Now, that's extreme, but not wanting a media player to be fooling around on the internet is a lot less extreme, and the OS should provide the user (or the sysadmin) with the tools necessary to enact such policy.
Sure, a lot of people won't bother about it, but they should have the option.
> Unless Microsoft writes big scary warnings for all non-green permissions that become less
> scary for publishers that can afford to pay $500 per year to VeriSign
I was thinking that the warnings would be the same irrespective of who publishes the software, but of course any given vendor might implement the thing badly, and Microsoft is no exception to that. Bear in mind, though, I was not talking specifically about Microsoft operating systems. Indeed, I would be somewhat startled if Windows were the first OS to provide such a permissions framework for applications. Actually, I would imagine that a somewhat obscure system would have to proof-of-concept the thing first, before it would be picked up by any major system, much less Microsoft.
> > An example of an orange permission would be deleting or changing any file to which
> > the user has write access (as opposed to just files the app itself creates).
> Including
Absolutely.
> If an operating system won't let a word processor read these files,
*Reading* them would probably be green (extreme privacy nuts can always dive into the details and disallow whatever they want) and applications that can usefully serve as the primary opener for a certain file type would presumably want that, and request it at install time.
But *changing* any old file in the user's My Documents folder is rather scarrier.
> So any capability system will need to have a way to move files in and out of applications'
> sandboxes. I haven't seen this in computer operating systems designed for home and home office use.
Two words: Save As.
(Yes, if you start disallowing apps from *reading* files they don't create, then you need a way to add an app to a file's whitelist, as it were. But I'd expect only the most extremely paranoid users to deny that permission to apps that they plan on actually using to open files, and extremely paranoid users will put up with a somewhat obscure interface for making exceptions.)
> > On the other hand, a lot of end users don't really want to install their own software in the
> > first place, and if computers came with more of the software they need out of the box
> But do computers come w
Cut that out, or I will ship you to Norilsk in a box.
> So if the user installs a new version of a program, would he or she need to always use Save As
> on all documents created with the old version of the program because they "belong" to a program
> file with a different SHA-256 hash? Would the user have to duplicate the browser profile every
> time, say, Firefox updates itself?
What do you think? Would those scenarios be a good outcome that would enhance security more than they would detract from usability?
I'm thinking no. I'm thinking there has to be a provision for updating a program to a new version and yet allowing it to be recognized as still being the same program.
> So if the user wants to grant additional permissions to an application, such as granting
> permission to access CDDB to an already-installed media player application, would the user
> need to reinstall the application?
No, there should be a mechanism for the user to go back later and make changes.
Most users would never need to use it though, because they'd just frob "yes" at install time, thereby granting the application all the privileges it wants. Only users (or sysadmins) who choose to deny applications some of the privileges they want would ever need to go back and make changes later.
> And how would install-time capability management apply to interpreters for bytecode-compiled
> languages such as Java and Python?
Ideally, if the OS can determine at launch time that the interpreter is going to run a certain file (e.g., because it's being launched by a shebang mechanism on Unix or a registry extension association on Windows), then in that case the permissions of the interpreted file would be granted by the OS, not those of the interpreter.
But in situations where the interpreter is launched first, and then used to open and run a file (which is possible with some interpreters), then the resulting program would by necessity have most of the permissions of the user.
Not that all of this implies that shells (both command shells and graphical shells) need the capability to launch a process with different capabilities. Most other applications would not need and should not have that ability.
Cut that out, or I will ship you to Norilsk in a box.
> > I'm thinking there has to be a provision for updating a program to a new
> > version and yet allowing it to be recognized as still being the same program.
> How would that be authenticated, in order to prevent various forms of malware
> from "updating" a program to a new version? Would it involve code signing,
> for which hobbyists do not have the $500 per year?
Actually, it could involve code-signing without requiring the developers to spend any money (other than for a little extra electricity their computers would use to do the work involved with computing the signature). If all you want is to prove that this new version was produced by the same people as the previous version, then it really just has to be signed with the *same* key that was used to sign something distributed with the previous version. There wouldn't have to be a certificate authority involved.
Indeed, if you were going to involve a CA, it would be for verifying *new* software, not updates.
Even without any code signing at all, installing updates is in any case restricted in all the same ways as installing new software.
First of all, even with the current state of affairs, the user needs admin privileges to install software (well, if it's being installed for all users of the system they do anyhow), so provided you take normal security precautions the user would _at least_ be prompted by sudo or UAC or what have you. (Yeah, I know, a lot of users are going to frob okay without reading it, but still, it's a barrier.)
Second, and perhaps more usefully, with application capabilities in place, apps like the web browser would not necessarily have the capability to launch programs that need admin privileges (e.g., installers). Obviously the web browser needs to be able to launch other programs (plugins if nothing else), but those don't need admin privs.
And third, when new software is installed, the user's going to be prompted to allow its capabilities.
Cut that out, or I will ship you to Norilsk in a box.