UAC gave Windows Vista a bad reputation for annoying prompts all the time, so in the interest of user experience and convenience, starting with Windows 7 Microsoft intentionally made it much less bulletproof: any Microsoft signed executable can bypass UAC. This includes common system executables which can be caused to load arbitrary dlls, this includes the control panel to turn off UAC entirely. It hasn't and won't be "fixed", it's just how it all works.
Unfortunately this results in constant annoying prompts.
I don't know what OSX does, but it seems like I'm prompted to escalate far less often than I would be on a high UAC system. How do the requirements compare?
I wonder whether various browser vendors are investigating ways to disable loading Wordpress sites given their propensity to being taken over by exploits. The browser vendors collectively disabled/stunted Flash, maybe it's time for Wordpress to go down?
Is Wordpress really that insecure, or is it the fact that it's the single most popular blogging platform out there, requires very minimal technical competence to set up, and therefore its users are doing dumb things with the configuration?
WordPress in itself isn't that unsafe; they are pretty diligent in fixing bugs and security issues. However that is not true about plugins, themes, various theme/plugin frameworks developed for WordPress[1], or custom-tailored things[2]. Also, we must factor in the end-users lack of technical competence[3].
Source: I work for a hosting company with lots of WordPress sites.
[1]: In my experience, there's lot of purposely back-doored, or easily exploitable themes and plugins. Also, let's not forget that users and/or developers often get these illegally (without even knowing they did it; it happened a few times).
[2]: The entry barrier for PHP/WordPress is extremely low and many of these developers are beginners and lack even basic understanding of security or even how things work; they base stuff off from an overly-simplified tutorial written by someone only slightly more experienced than they are. There are also inherent language and CMS issues here, but I won't go into those.
[3]: We actually have users who don't to update WordPress or any of the plugins for ages. AGES! The other day, I had to argue with a client why having a WordPress version from 2006 (something from the 2.0.x release series) is a bad idea. This is either because the developer stopped supporting and abandoned development of some component their site depends on, or because of legacy custom-tailored code that was a once-off purchase.
As a fellow shared hosting engineer I pretty much agree with [1] and [2], and for [3] I also feel your pain, but we don't mess about any more arguing the toss.
We now scan for egregiously out of date WordPress installs and warn customers that their site will be at risk of being disabled if they don't upgrade to the latest version. If after a couple of days we see no action then we pull the site.
If we detect sites serving dodgy links then they're instantly shut down until the customer can prove they've secured the site.
In 99.9% of cases our customers are happy we do this because they're mostly businesses and serving malware damages their brand and reputation. We do get the occasional user who refuses to co-operate, and if they do we serve them notice to take their business elsewhere.
> If we detect sites serving dodgy links then they're instantly shut down until the customer can prove they've secured the site.
We have a similar approach to this actually. The exception being that we clean the malware ourselves, sadly. I tried to say is a bad idea multiple times, but no luck. What makes things worse, we have a few "spoiled" clients that keep getting their websites hacked (there's 3 such WordPress and Joomla development resellers) and they started expecting us to clean their websites. Sigh
Also, I tried to argue a few times that we do the scan-and-warn thing, but I got turned down with the counter argument that it would generate more backscatter on our support department than it would be worth it.
How can a browser practice voodoo to find out what's running on the server? Flash is a client side technology, and the browsers (clients) got rid of it. There is absolutely no way to tell that a website is running Wordpress. Also, why would the browser even care what happens on the server? Blocking websites that use Wordpress is about as doable as blocking websites whose sysadmins have mohawks.
Voodoo? It's easy enough for automated toolkits to determine when Wordpress is running on a server by querying well known paths. Having client browsers perform the same trick when connecting to new domains isn't the black magic you're trying to make it out to be.
Browsers are not the internet police, and browser vendors should not be in the business of deciding which server software it wants to talk to.
Flash and other plugins are a completely different thing. Running flash is not a core functionality of the browser. Making HTTP requests and rendering HTML is.
Browser vendors have already inserted themselves into this role by selectively blocking Flash, messing around with how certificates are presented by the browser to imply certain things ("green lock == safe") when no such implication can be made, blocking and/or allowing ad blockers, etc.
Maybe you're too young to remember when everyone had to update their Flash installations every week because that product was improperly sandboxed, so you think that the issue was purely battery related. Blocking and restricting flash is as much about security as battery, more-so in my opinion.
But OK, let's compromise -- rather than preventing connections to Wordpress sites, maybe they could draw a big red line through a picture of the Wordpress logo, and then perhaps warn the user that this site is or soon will be serving malware.
> Browser vendors have already inserted themselves into this role by selectively blocking Flash, messing around with how certificates are presented by the browser to imply certain things ("green lock == safe") when no such implication can be made, blocking and/or allowing ad blockers, etc.
If you'd read my reply, you'd see I addressed this point.
> Maybe you're too young to remember when everyone had to update their Flash installations every week because that product was improperly sandboxed, so you think that the issue was purely battery related. Blocking and restricting flash is as much about security as battery, more-so in my opinion.
Yes, it is. And again, I addressed this in my post. I suggest reading it and responding to the points made. The key is the core functionality of the browser, of which the plugin API is not.
As for TLS, the CA system is completely broken. I wish we had something better. Given that we don't have anything that squares zooko's triangle that's likely to get uptake today (I don't see namecoin having reached a state where it's ready for large-scale deployment), I wonder what you'd like to do there instead?
The "green lock" EV stuff is clearly a racket. Browser vendors shouldn't put stock in it, but they do. I don't see how that's an argument for refusing to render HTML they don't like.
The blame should be on MS here. Why does this OS happily run unsigned executables from random sites, random emails, etc? The days where that's a common use case are long behind us and for legitimate uses, end users can go into the control panel and whitelist exe's on a per exe basis. Its way, way too easy to fool a Windows user into running your code.
19 comments
[ 3.1 ms ] story [ 53.8 ms ] thread> And stopping: Windows Security Center Service Windows Defender Windows Update Service Windows Error Reporting Service and BITS
Won't these actions require administrator privileges? How do the program escalate its privilege if it starts by user clicking on a js file?
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
If UAC is set to Medium (the default).
If you're serious about security you should set it to High.
I don't know what OSX does, but it seems like I'm prompted to escalate far less often than I would be on a high UAC system. How do the requirements compare?
Source: I work for a hosting company with lots of WordPress sites.
[1]: In my experience, there's lot of purposely back-doored, or easily exploitable themes and plugins. Also, let's not forget that users and/or developers often get these illegally (without even knowing they did it; it happened a few times).
[2]: The entry barrier for PHP/WordPress is extremely low and many of these developers are beginners and lack even basic understanding of security or even how things work; they base stuff off from an overly-simplified tutorial written by someone only slightly more experienced than they are. There are also inherent language and CMS issues here, but I won't go into those.
[3]: We actually have users who don't to update WordPress or any of the plugins for ages. AGES! The other day, I had to argue with a client why having a WordPress version from 2006 (something from the 2.0.x release series) is a bad idea. This is either because the developer stopped supporting and abandoned development of some component their site depends on, or because of legacy custom-tailored code that was a once-off purchase.
We now scan for egregiously out of date WordPress installs and warn customers that their site will be at risk of being disabled if they don't upgrade to the latest version. If after a couple of days we see no action then we pull the site.
If we detect sites serving dodgy links then they're instantly shut down until the customer can prove they've secured the site.
In 99.9% of cases our customers are happy we do this because they're mostly businesses and serving malware damages their brand and reputation. We do get the occasional user who refuses to co-operate, and if they do we serve them notice to take their business elsewhere.
We have a similar approach to this actually. The exception being that we clean the malware ourselves, sadly. I tried to say is a bad idea multiple times, but no luck. What makes things worse, we have a few "spoiled" clients that keep getting their websites hacked (there's 3 such WordPress and Joomla development resellers) and they started expecting us to clean their websites. Sigh
Also, I tried to argue a few times that we do the scan-and-warn thing, but I got turned down with the counter argument that it would generate more backscatter on our support department than it would be worth it.
Flash and other plugins are a completely different thing. Running flash is not a core functionality of the browser. Making HTTP requests and rendering HTML is.
Browser vendors have already inserted themselves into this role by selectively blocking Flash, messing around with how certificates are presented by the browser to imply certain things ("green lock == safe") when no such implication can be made, blocking and/or allowing ad blockers, etc.
Maybe you're too young to remember when everyone had to update their Flash installations every week because that product was improperly sandboxed, so you think that the issue was purely battery related. Blocking and restricting flash is as much about security as battery, more-so in my opinion.
But OK, let's compromise -- rather than preventing connections to Wordpress sites, maybe they could draw a big red line through a picture of the Wordpress logo, and then perhaps warn the user that this site is or soon will be serving malware.
If you'd read my reply, you'd see I addressed this point.
> Maybe you're too young to remember when everyone had to update their Flash installations every week because that product was improperly sandboxed, so you think that the issue was purely battery related. Blocking and restricting flash is as much about security as battery, more-so in my opinion.
Yes, it is. And again, I addressed this in my post. I suggest reading it and responding to the points made. The key is the core functionality of the browser, of which the plugin API is not.
As for TLS, the CA system is completely broken. I wish we had something better. Given that we don't have anything that squares zooko's triangle that's likely to get uptake today (I don't see namecoin having reached a state where it's ready for large-scale deployment), I wonder what you'd like to do there instead?
The "green lock" EV stuff is clearly a racket. Browser vendors shouldn't put stock in it, but they do. I don't see how that's an argument for refusing to render HTML they don't like.