I know this will not change until Monday, but is it really necessary to transmit the URL? Wouldn't the md5 of the URL do? I know it's easy to find WP-Blogs via google. But imagine have them all nicely in a database - All of them. Including version, plugins and so on. If that database gets public and you find a security bug in one of the plugins - there are enough - you can start a _very_ effective attack!
1. no need to even send the version to know there is a need to update (just get the latest version number and compare to the current version).
2. if wp send information about the blog, the users should be aware of this and be able to turn it off. this is a bad publicity bomb waiting to go off.
Moritz 'Morty' Strübe wrote: > I know this will not change until Monday, but is it really necessary to > transmit the URL? Wouldn't the md5 of the URL do? I know it's easy to > find WP-Blogs via google. But imagine have them all nicely in a database > - All of them. Including version, plugins and so on. If that database > gets public and you find a security bug in one of the plugins - there > are enough - you can start a _very_ effective attack!
Your logic is flawed. You assume that someone looking to exploit won't attack the latest version. This is usually untrue. If a serious exploit is found, hackers usually just Google for "WordPress" (it's already on your site for "powered by WordPress") or like wp-login.php and then attempt to exploit it, regardless of version. If some database somewhere somehow did get leaked, then all it'd do is just make the hackers job easier -- it wouldn't enable them.
And by checking for an update, your server's IP address is sent automatically. It wouldn't be hard to reverse lookup that IP.
Simply put, if you really insist on wearing a tin foil hat, it's uber easy to disable the automatic update checker. For the other 99.99999% of people out there, this feature will be a godsend to them in both terms of new features and more importantly, the _only_ real way to make sure your site doesn't get hacked -- by running the latest version.
On 9/23/07, Moritz 'Morty' Strübe <mo...@gmx.net> wrote:
> I know this will not change until Monday, but is it really necessary to > transmit the URL? Wouldn't the md5 of the URL do? I know it's easy to > find WP-Blogs via google. But imagine have them all nicely in a database > - All of them. Including version, plugins and so on. If that database > gets public and you find a security bug in one of the plugins - there > are enough - you can start a _very_ effective attack!
On Sun, 2007-09-23 at 03:52 -0700, Viper007Bond wrote: > And by checking for an update, your server's IP address is sent > automatically. It wouldn't be hard to reverse lookup that IP.
That's not true. Most blogs are on virtual hosting environments, where many domains are assigned to one IP. And even if in fact you have only one domain on your server, the party performing a reverse lookup will not be able to tell that. Therefore it's a large difference whether you log the client IP or you transmit the blog URL. And this is the very reason why Automattic logs the Blog URL.
> Simply put, if you really insist on wearing a tin foil hat, it's uber easy > to disable the automatic update checker. For the other 99.99999% of people > out there, this feature will be a godsend to them in both terms of new > features and more importantly, the _only_ real way to make sure your site > doesn't get hacked -- by running the latest version.
It's none of WP's business who runs a blog. I know some people don't care about privacy, I however do, and I disapprove anybody trying to gather more information than neccessary about me and what I do. Unless anybody can give me a good explaination for why Wordpress/Automattic needs to know my URLs.
By the way, I was rather shocked when I saw what big bunch of data Akismet transmits on connecting to its server. Why the heck does Akismet transmit *all* my $_SERVER environment variables? That's a big reason to mistrust Akismet, unless there are *very* good reasons for that. And I doubt there are any.
On Sun, 2007-09-23 at 13:12 +0200, Alex Günsche wrote: > By the way, I was rather shocked when I saw what big bunch of data > Akismet transmits on connecting to its server. Why the heck does Akismet > transmit *all* my $_SERVER environment variables? That's a big reason to > mistrust Akismet, unless there are *very* good reasons for that. And I > doubt there are any.
By the way, does Rule No. 1 of Automattic's privacy policy still apply?
"We don't ask you for personal information unless we truly need it. (We can?t stand services that ask you for things like your gender or income level for no apparent reason.)"
> Your logic is flawed. You assume that someone looking to exploit won't > attack the latest version. This is usually untrue.
And as the version gets transmitted you also get a nice list of outdated blogs.
> If a serious exploit is > found, hackers usually just Google for "WordPress"
Didn't I already say I thought of that?
> (it's already on your > site for "powered by WordPress") or like wp-login.php and then attempt to > exploit it, regardless of version. If some database somewhere somehow did > get leaked, then all it'd do is just make the hackers job easier -- it > wouldn't enable them.
That's why I'm referring to plugins. Opposed to Wordpress plugins have fewer installations and often maintained by a single person. Fewer installations makes them less interesting for attacks, because it is not always easy to find them. But if you have a nice list, including the version in use.... The problem with the single person is, that this person is maintaining the plugin in his spare time. Opposed to Wordpress it self where a lot of people, making money, are interested in Wordpress being safe.
> And by checking for an update, your server's IP address is sent > automatically. It wouldn't be hard to reverse lookup that IP.
First of all you don't need a reverse lookup as you can just enter the IP. Second if you do a reverse lookup you often only get something linke serverxy.hoster.tld, because most people don't want to spend so much money for a v-server or even a real server. Therefore the IP doesn't help you that much. Of couse you can check all the Domains on that Host, but you would also have to check for subdomains and or subdirectories. Of course there are people where you can start an attack using the IP or with the domain you get with a reverse lookup, but those are not the installations I'm worried about. BTW: Being able to access a server by IP number or the reverse DNS-entry is a security flaw in my eyes, but that is another matter. Or in short: The IP helps you, but not much.
> Simply put, if you really insist on wearing a tin foil hat, it's uber easy > to disable the automatic update checker.
I do not want to do that! And I never suggested that! (I hope you know what a md5 is....)
> For the other 99.99999% of people > out there, this feature will be a godsend to them in both terms of new > features and more importantly, the _only_ real way to make sure your site > doesn't get hacked -- by running the latest version.
But still that is no reason to tell everybody which version I'm running. And sorry I'm not able to update my Software 24/7. This is no f*ck'n pro/contra update checking discussion. It is a: Do you really need to collect all this information? And do you know that collecting it is a reasonable threat? Because if there is a security update and someone does get that list he can run an attack on those hosts who haven't updated yet.
> On 9/23/07, Moritz 'Morty' Strübe <mo...@gmx.net> wrote:
>> I know this will not change until Monday, but is it really necessary to >> transmit the URL? Wouldn't the md5 of the URL do? I know it's easy to >> find WP-Blogs via google. But imagine have them all nicely in a database >> - All of them. Including version, plugins and so on. If that database >> gets public and you find a security bug in one of the plugins - there >> are enough - you can start a _very_ effective attack!
We were discussing this on a political blogger mailing list I am on. There are about 30 WP users on that list. As of this morning, 18 of them said they will not be moving to WP 2.3 solely because of this. Like one of the bloggers said; "If they are not telling you about this feature when you upgrade, then when will they take other personal information like emails and secretly send them to a server".
I know this is a small micro-sampling of WP users, but it has had me thinking. While most of us on the mailing list know Matt and that he wouldn't be out to do something like that, how about the other 99%+ WP users out there who don't know him? In a time when internet privacy concerns are in our daily newspapers, I believe a lot more consideration should be given to this before rolling it out. IMHO the best option would be to include the feature as a bundled plugin. That way people can opt into it.
Personally, my biggest complaint is with the persistence of this notification. I changed the version # just so I could see it. There really needs to be a way to close this out. Having it show all the time is a nag. I say make it so when someone closes it, it will come back every 24 hours or so. It shouldn't be that bad to implement a way to close this out.
- Put a close link on the notification. Have it remove it either via ajax or a get method (possibly read in admin.php). When it's closed you set an option HideUpdateNotification_{$user->ID}. Set that with the currenttime+time_to_hide_it. This is option is checked and if the option time<currenttime, go ahead and show it again (then the person can close it again if they so choose).
>-----Original Message----- >From: wp-hackers-boun...@lists.automattic.com [mailto:wp-hackers- >boun...@lists.automattic.com] On Behalf Of Alex Günsche >Sent: Sunday, September 23, 2007 7:16 AM >To: wp-hack...@lists.automattic.com >Subject: Re: [wp-hackers] Plugin update & security / privacy
>On Sun, 2007-09-23 at 13:12 +0200, Alex Günsche wrote: >> By the way, I was rather shocked when I saw what big bunch of data >> Akismet transmits on connecting to its server. Why the heck does >Akismet >> transmit *all* my $_SERVER environment variables? That's a big reason >to >> mistrust Akismet, unless there are *very* good reasons for that. And I >> doubt there are any.
>By the way, does Rule No. 1 of Automattic's privacy policy still apply?
>"We don't ask you for personal information unless we truly need it. (We >can?t stand services that ask you for things like your gender or income >level for no apparent reason.)"
On Sun, 2007-09-23 at 08:37 -0400, Jamie Holly wrote: > We were discussing this on a political blogger mailing list I am on. There > are about 30 WP users on that list. As of this morning, 18 of them said they > will not be moving to WP 2.3 solely because of this. Like one of the > bloggers said; "If they are not telling you about this feature when you > upgrade, then when will they take other personal information like emails and > secretly send them to a server".
I wouldn't go so far to accuse WP/Automattic of *secretly* submitting data. However, I dislike it when software tries to gather too much data, and other people obviously agree. (Just imagine what would happen if, say, MS IIS would send your server environment variables to a MS server.) So I always look for ways to cut off this kind of behaviour.
Anyway, not upgrading is a bad idea, you know the reasons. You *could* go back to 2.0.x, but not without much effort and potential issues.
As for Akismet, one can simply find the following section and comment it out:
foreach ( $_SERVER as $key => $value ) if ( !in_array( $key, $ignore ) ) $comment["$key"] = $value;
Luckily, this modification doesn't affect Akismet's functioning, and if it would (e.g. in a future version), it wouldn't be a problem faking this data. As Akismet resides in wp-content/ the plugin isn't directly affected by core upgrades either.
> - Put a close link on the notification. Have it remove it either via ajax or > a get method (possibly read in admin.php). When it's closed you set an > option HideUpdateNotification_{$user->ID}. Set that with the > currenttime+time_to_hide_it. This is option is checked and if the option > time<currenttime, go ahead and show it again (then the person can close it > again if they so choose).
Sounds interesting. However, I have an idea for a hack to prevent the submission of the blog URL in this specific case, and I think I'll release it as a plugin in case it should become neccessary.
By the way, could you (Jamie) send me a link to your list, specifically to the mentioned discussion, to my e-mail address? Thanks.
To get some facts out added some debugging output. Notice that there are 11k of data transmitted. Also of course your Wordpress version and your url (which I already encapsulated in a md5). IMHO a list of plugin names and a answer with the current version numbers is enough data to be transmitted.
Moritz 'Morty' Strübe wrote: > To get some facts out added some debugging output. > Notice that there are 11k of data transmitted. Also of course your > Wordpress version and your url (which I already encapsulated in a md5). > IMHO a list of plugin names and a answer with the current version > numbers is enough data to be transmitted.
Omry, although I do agree with you, I'm not sure whether you understand the situation. We are not discussing what we - in this case they, as I am not a core-dev and I think neither are you - should do or what is the best way to solve this problem. The code is there and tested. The release is Monday, tomorrow. There will be _no_ changes is the way it works. The only thing that might happen, is that the URL get's wrapped in a md5 or better not transmitted at all. Cheers Morty
> maybe we should only send plugin file, version and name.
> also, in the spirit of my original proposal:
> 1. this should not be bundled with the new version check.
> 2. users should explicitly agree to send info before WP sends anything.
> Moritz 'Morty' Strübe wrote:
>> To get some facts out added some debugging output. >> Notice that there are 11k of data transmitted. Also of course your >> Wordpress version and your url (which I already encapsulated in a md5). >> IMHO a list of plugin names and a answer with the current version >> numbers is enough data to be transmitted.
On Sun, 2007-09-23 at 08:37 -0400, Jamie Holly wrote: > We were discussing this on a political blogger mailing list I am on. There > are about 30 WP users on that list. As of this morning, 18 of them said they > will not be moving to WP 2.3 solely because of this.
Ok, before you guys don't upgrade at all, here's a little plugin which will completely(!) suppress the version checker.
------- SNIP ------- <?php /* Plugin Name: No Update Checker Description: *Very* rough hack to suppress the WordPress update checker. Version: 0.1 */
function noupdatechecker() { if ( !defined('WP_INSTALLING') ) define('WP_INSTALLING', true);
Save the above as noupdatechecker.php (or whatever) in wp-content/plugins/. No whitespace must be outside the PHP tags! Then activate the plugin in the admin panel.
Note: The plugin deactivates the version checker by defining WP_INSTALLING, a constant that is used in other parts of the core, too. I had a quick grep, looked at the respective positions, and tested the associated WP features -- the normal functioning of WordPress seems not to be impacted by this hack. Anyway, if strange things happen due to its usage, let me know. Feedback is apprechiated (e-mail me).
You confused me a bit with the suggestion to add plugin information.
in this case, I agree that sending md5 of the url is a step in the right direction.
in all truth, I don't see why the client even NEED to send it's version. it can be nice for statistics purpose, but nothing more..
it can just as easily be implemented by requesting the latest version number from the server and comparing it to the current version.
but as you said, it's probably already too late for this.
I think it's a shame that the concerns raised in this mailing list in past few weeks about this were ignored.
Moritz 'Morty' Strübe wrote: > Omry, although I do agree with you, I'm not sure whether you understand > the situation. We are not discussing what we - in this case they, as I > am not a core-dev and I think neither are you - should do or what is the > best way to solve this problem. The code is there and tested. The > release is Monday, tomorrow. There will be _no_ changes is the way it > works. The only thing that might happen, is that the URL get's wrapped > in a md5 or better not transmitted at all. > Cheers > Morty
> On Sun, 2007-09-23 at 08:37 -0400, Jamie Holly wrote: > > We were discussing this on a political blogger mailing list I am on. There > > are about 30 WP users on that list. As of this morning, 18 of them said they > > will not be moving to WP 2.3 solely because of this.
> Ok, before you guys don't upgrade at all, here's a little plugin which > will completely(!) suppress the version checker.
> ------- SNIP ------- > <?php > /* > Plugin Name: No Update Checker > Description: *Very* rough hack to suppress the WordPress update checker. > Version: 0.1 > */
> Save the above as noupdatechecker.php (or whatever) in > wp-content/plugins/. No whitespace must be outside the PHP tags! Then > activate the plugin in the admin panel.
> Note: The plugin deactivates the version checker by defining > WP_INSTALLING, a constant that is used in other parts of the core, too. > I had a quick grep, looked at the respective positions, and tested the > associated WP features -- the normal functioning of WordPress seems not > to be impacted by this hack. Anyway, if strange things happen due to its > usage, let me know. Feedback is apprechiated (e-mail me).
Cool, that's good to know. However, as far as I see, this won't stop wp-includes/update.php from executing. That file contains a function that is registered via the 'init' hook, and it is loaded on each page of the admin panel.
> Cool, that's good to know. However, as far as I see, this won't stop > wp-includes/update.php from executing. That file contains a function > that is registered via the 'init' hook, and it is loaded on each page of > the admin panel.
On Sun, 2007-09-23 at 16:44 +0100, John Blackbourn wrote: > Alex, if you're looking at wp-includes/update.php then that function > is for the core update system (which can be disabled with my other > plugin http://wordpress.org/extend/plugins/disable-wordpress-core-update/).
> The plugin update system is handled in wp-admin/incluces/update.php > and is called on the load-plugins.php hook.
Great! This is indeed much better than my solution -- I also should have thought of remove_action(). Thumbs up! :-)
On Sep 23, 2007, at 5:35 AM, Moritz 'Morty' Strübe wrote:
> I know this will not change until Monday, but is it really > necessary to > transmit the URL? Wouldn't the md5 of the URL do? I know it's easy to > find WP-Blogs via google. But imagine have them all nicely in a > database > - All of them. Including version, plugins and so on. If that database > gets public and you find a security bug in one of the plugins - there > are enough - you can start a _very_ effective attack!
I don't know, but I'm trying to find out. It seems unnecessary to me. And it definitely works without it (or with a different -- anonymous -- string). Matt wrote that code, so I'll try to get a hold of him today.
Moritz 'Morty' Strübe wrote: > I know this will not change until Monday, but is it really necessary to > transmit the URL?
Your blog URL and version has been sent by default for 4+ years to every ping service in the world, including Ping-O-Matic, every time you make a post. Of course you can turn that off, just like you can turn update notification off, but statistically no one does.
The only new information being sent by the update checker is PHP version and a list of plugins. If you don't like that feature, please install a plugin to disable it:
Of course don't forget the WP dev blog and planet RSS feeds, and most importantly the incoming links feed which ALSO transmits your blog URL.
I would also recommend disabling the updates in Mac OS X, Firefox, Windows, Thunderbird, Adobe Photoshop, and any other third-party applications you have. As all of those are tied to your personal IP and not your server IP they have far more implications for privacy.
> If that database > gets public and you find a security bug in one of the plugins - there > are enough - you can start a _very_ effective attack!
Such an attack would not be more effective, it would just be more efficient. Historically, however, scripts that attack against WordPress don't bother checking the version or if a plugin is there or not, they just seek out every WP blog and check the specific capability or vulnerability.
Nevertheless, we're beefing up the infrastructure and security of WordPress.org, which Barry is working on right this instant. In 2 years of running WordPress.com and Akismet, two extraordinarily high-visibility targets, there has never been a problem on a server Barry set up. The only problems we've had (once on WP.org, once on PhotoMatt) have been things I set up, and I'm not setting up these new ones. :)
I think this feature is actually going to dramatically improve the security of WordPress overall. We all saw the survey that 95% of WP blogs were vulnerable. That didn't even look a plugins. I think the survey was flawed, but you still can't deny that for most people knowing there is an update and actually updating just doesn't happen, and this is a necessary first step. If the only "trade-off" is sending an ALREADY PUBLIC blog URL to wordpress.org, then great!
I would like to remind the participants of this thread that WP.org != Automattic, so to be fair to the members of both please distinguish which you're referring to.
> Moritz 'Morty' Strübe wrote: >> I know this will not change until Monday, but is it really necessary to >> transmit the URL?
> Your blog URL and version has been sent by default for 4+ years to > every ping service in the world, including Ping-O-Matic, every time > you make a post. Of course you can turn that off, just like you can > turn update notification off, but statistically no one does.
> The only new information being sent by the update checker is PHP > version and a list of plugins. If you don't like that feature, please > install a plugin to disable it:
> Of course don't forget the WP dev blog and planet RSS feeds, and most > importantly the incoming links feed which ALSO transmits your blog URL.
> I would also recommend disabling the updates in Mac OS X, Firefox, > Windows, Thunderbird, Adobe Photoshop, and any other third-party > applications you have. As all of those are tied to your personal IP > and not your server IP they have far more implications for privacy.
I think you didn't get my point. This is not about what I write, but what information gets collected at one point and whether I can decide about that. Of course I have an interest in spreading my word. And I already said that it is no problem being listed on google. It's the combination of Plugins + Versions + Url.
>> If that database >> gets public and you find a security bug in one of the plugins - there >> are enough - you can start a _very_ effective attack!
> Such an attack would not be more effective, it would just be more > efficient. Historically, however, scripts that attack against > WordPress don't bother checking the version or if a plugin is there or > not, they just seek out every WP blog and check the specific > capability or vulnerability.
Well it will also be more effective, because less people will notice. And yes you are right it will be more efficient, something that is probably worth a bit of money.
> Nevertheless, we're beefing up the infrastructure and security of > WordPress.org, which Barry is working on right this instant. In 2 > years of running WordPress.com and Akismet, two extraordinarily > high-visibility targets, there has never been a problem on a server > Barry set up. The only problems we've had (once on WP.org, once on > PhotoMatt) have been things I set up, and I'm not setting up these new > ones. :)
NSA, CIA, FBI, NASA, all thought their systems are safe. And if there is nothing to loose there is nothing to bother. And as I said. I have no problem with collecting data, but with being able to relate them.
> I think this feature is actually going to dramatically improve the > security of WordPress overall. We all saw the survey that 95% of WP > blogs were vulnerable. That didn't even look a plugins. I think the > survey was flawed, but you still can't deny that for most people > knowing there is an update and actually updating just doesn't happen, > and this is a necessary first step.
I'm with you.
> If the only "trade-off" is sending an ALREADY PUBLIC blog URL to > wordpress.org, then great!
Once again. It's not about the blog-URL, its about the relationship BlogURL & plugins & their versions. Blogurl | plugins & their versions is no problem with me.
>> I know this will not change until Monday, but is it really >> necessary to transmit the URL?
> Your blog URL and version has been sent by default for 4+ years > to every ping service in the world, including Ping-O-Matic, > every time you make a post.
So, this is a bit confusing...
- Ping-O-Matic is receiving my "version"? Huh?
- Automattic's not getting this data in pre-2.3 versions, correct? If that's the case, then the (obvious) problem with that is that somebody decided to flip this switch without making it opt-in.
On Sep 23, 2007, at 3:35 PM, Matt Mullenweg wrote:
> I think this feature is actually going to dramatically improve the > security of WordPress overall. We all saw the survey that 95% of WP > blogs were vulnerable. That didn't even look a plugins. I think the > survey was flawed, but you still can't deny that for most people > knowing there is an update and actually updating just doesn't > happen, and this is a necessary first step. If the only "trade-off" > is sending an ALREADY PUBLIC blog URL to wordpress.org, then great!
Back up a minute. Why is the blog URL needed? The update notification functionality works fine without it. You don't need it for statistics purposes -- wp_hash('update-notification') 's output would be just as unique. How do users benefit by sending their blog URL? I think the onus is on us to show why it is necessary or beneficial. If we can't, it shouldn't be there.
On Sun, Sep 23, 2007 at 05:54:25PM -0400, Mark Jaquith wrote: > On Sep 23, 2007, at 3:35 PM, Matt Mullenweg wrote:
> >I think this feature is actually going to dramatically improve the > >security of WordPress overall. We all saw the survey that 95% of WP > >blogs were vulnerable. That didn't even look a plugins. I think the > >survey was flawed, but you still can't deny that for most people > >knowing there is an update and actually updating just doesn't > >happen, and this is a necessary first step. If the only "trade-off" > >is sending an ALREADY PUBLIC blog URL to wordpress.org, then great!
> Back up a minute. Why is the blog URL needed? The update > notification functionality works fine without it. You don't need it > for statistics purposes -- wp_hash('update-notification') 's output > would be just as unique. How do users benefit by sending their blog > URL? I think the onus is on us to show why it is necessary or > beneficial. If we can't, it shouldn't be there.
Thanks, Mark -- I think that is the correct question.
And the same question should be asked about the other data that is sent. Why are the plugin versions sent to the server? It should be enough to send the plugin filename and/or name, so the server can return a list of current versions. The client (WP) can then figure out which plugins need updating.
|
