5 ms·

Automatic updating of bad code is always better than non automatic updating of very good code? All software has bugs, the easier and quicker to fix them and ro

Automatic updating of bad code is always better than non automatic updating of very good code? All software has bugs, the easier and quicker to fix them and roll out those fixes the better?

stephenr 9y ago
The method of updating has to be considered. If your auto-update system also means a single RCE vulnerability can then embed malicious content into the program itself, that is worse than non automatic updates.
- goldenkey 9y ago
  It's a known hard problem. Capability based permissions vs access control based permissions. I would trust wordpress to keep their signing keys safe. https://en.m.wikipedia.org/wiki/Confused_deputy_problem https://en.m.wikipedia.org/wiki/Confused_deputy_problem
  - stephenr 9y ago
    It’s nothing to do with signing keys. If php has permission to extract an archive with new files over the current ones, it has permission to write a malicious file over a current one. I’m not talking about a vulnerability on the wordpress central infra that delivers a malicious update via the legitimate update path. I’m talking about a vulnerability in the millions of wordpress installs that have filesystem permissions to overwrite themselves, to facilitate “auto update”.
    - mgkimsal 9y ago
      This is almost always at the core of WP exploits. Sure, there have been some SQL injection and XSS, but almost every WP exploit I've seen in person has been related to files being able to be written to the filesystem and become a publicly accessible URL immediately. I don't do as much with WP these days, but have worked with it some over the years, and work with multiple folks in the geographic area who primarily do WP work (friends with folks who run WP meetings and do all-WP work, etc). I've seen dozens of exploited systems in the last 2-3 years, and been asked to help 'clean them up'. Every single one of those was some variation on some bot exploiting some code (in core or in a plugin) that allowed for some obfuscated code to be written to a publicly accessible directory, with names like "includes.php" or "sys.php" (things like that) - common words that no one who is not a WP expert would even think to question in the first place (no one leaves BACKDOOR_EXPLOIT.php as a file name, for example). Yes, you can install stuff like wordfence and similar tools to continually scan your disk to look for 'infections', but... why allow those to be written to the drive in the first place? I know the answer is "convenience", but it's been a huge community price to pay.
  - regecks 9y ago
    Can't reply to stephenr because comment thread is too deep, but it's perfectly possible to run WordPress without write permissions anywhere near executable code and then to schedule automatic updates at a different privilege level. Since this is done extremely rarely, that leads me to believe that its more of a cultural problem (perhaps with the WordPress team, even) than a technical one. Spent 5 years in shared PHP web hosting, can confirm that most of the people are muddling through with the bare minimum of understanding to get WordPress going.
    - stephenr 9y ago
      > schedule automatic updates at a different privilege level That is inherently not the default for wordpress, and at that point you may as well be installing via deb/rpm. I didn’t say scheduled updated are bad I said a self writable web app is a fucking security nightmare.
    - reificator 9y ago
      > Can't reply to stephenr because comment thread is too deep I've found that clicking a comment's timestamp to view a permalink to it will usually allow replying.
  - temprature 9y ago
    > I would trust wordpress to keep their signing keys safe. What signing keys? Wordpress's automatic updates aren't signed, so your trust is horrendously misplaced. Someone already did the work for them to implement it[0], and rather than commit it, a Wordpress developer wrote a blogpost saying signing isn't really that important[1]. [0] https://core.trac.wordpress.org/ticket/39309 https://core.trac.wordpress.org/ticket/39309 [1] https://medium.com/@photomatt/wordpress-and-update-signing-51501213e1 https://medium.com/@photomatt/wordpress-and-update-signing-5...
- mgkimsal 9y ago
  I'd really like if WP offered an inbuilt way of doing installs/updates via ssh. defaults seem to require plaintext FTP credentials to itself. I know there was an ssh plugin, and I know it couldn't be the only option (or perhaps even default), but having it as an available option on install would still be nice...
  - stephenr 9y ago
    I’m not sure that really improves the situation much. It’d still have effective write permission to itself. On shared hosting I’d have thought a user-account cronjob calling the app via cli (not via curl) could do the updates - but wordpress has always veered for “offer a shit solution to everyone” over “offer a secure solution to some subset of everyone”.
    - mgkimsal 9y ago
      by no means is it a big improvement, but it's forced me, on more than one occasion, to end up needing to enable an FTP server just to accommodate this behaviour. Just... more work (and increased insecurity, even if only for a small window of time). my default for wp installs is to just take write permission off everything all the time, then re-enable it when I know I will be doing something needing to write (updates, etc). There are likely some actual WP users who are not technical yet actually use the system to do their own content updates, but almost everyone I know who's using wordpress is managing it on behalf of their clients, doing all the content updates for them. These people could/should probably get familiar enough with ssh and stronger security practices, but the 'one click update' for themes/plugins/core seems to give a very strong (but ...problematic) sense of security.
  - jlgaddis 9y ago
    You can always just grab a tarball, uncompress it locally, and then connect to the server with your favorite SFTP client to upload the new files to the server. It's not exactly elegant but it is possible. I did that more than once back in the good ol' days before the fancy schmancy automatic updates. After you do it a few times, though, you'll probably just give up and modify the file permissions so that WordPress can update itself at which point... If the user that WordPress (or the web server stack, I suppose) is running as has write permissions on the directory where WordPress lives, it can update itself directly without having to FTP to localhost or whatever. Of course, typically we'd say it would be a bad idea for the application to be able to do that but blah blah risk assessment blah blah trade-offs blah blah ... For a long while, this was a widely accepted/standard way of hosting multiple customers on a shared web server, using something like suexec+php-cgi or (even better, IMO) mpm-itk. Then, each customer's WordPress site would run under its own uid/gid in order to isolate them from one another. A single customer could break their own instance or allow it to get hacked over and over again, but at least it couldn't get to other users' sites. I'm not sure how the large shared web hosts are handling this nowadays or if anything has even changed. (Edit: After reading your other comments, mgkimsal, it's obvious that you already know all of this but I'm not going to delete/edit my comment now.)

Automatic updating of bad code is always better than non automatic updating of very good code? All software has bugs, the easier and quicker to fix them and roll out those fixes the better?

stephenr 9y ago

The method of updating has to be considered. If your auto-update system also means a single RCE vulnerability can then embed malicious content into the program itself, that is worse than non automatic updates.

goldenkey 9y ago
It's a known hard problem. Capability based permissions vs access control based permissions. I would trust wordpress to keep their signing keys safe. https://en.m.wikipedia.org/wiki/Confused_deputy_problem https://en.m.wikipedia.org/wiki/Confused_deputy_problem
- stephenr 9y ago
  It’s nothing to do with signing keys. If php has permission to extract an archive with new files over the current ones, it has permission to write a malicious file over a current one. I’m not talking about a vulnerability on the wordpress central infra that delivers a malicious update via the legitimate update path. I’m talking about a vulnerability in the millions of wordpress installs that have filesystem permissions to overwrite themselves, to facilitate “auto update”.
  - mgkimsal 9y ago
    This is almost always at the core of WP exploits. Sure, there have been some SQL injection and XSS, but almost every WP exploit I've seen in person has been related to files being able to be written to the filesystem and become a publicly accessible URL immediately. I don't do as much with WP these days, but have worked with it some over the years, and work with multiple folks in the geographic area who primarily do WP work (friends with folks who run WP meetings and do all-WP work, etc). I've seen dozens of exploited systems in the last 2-3 years, and been asked to help 'clean them up'. Every single one of those was some variation on some bot exploiting some code (in core or in a plugin) that allowed for some obfuscated code to be written to a publicly accessible directory, with names like "includes.php" or "sys.php" (things like that) - common words that no one who is not a WP expert would even think to question in the first place (no one leaves BACKDOOR_EXPLOIT.php as a file name, for example). Yes, you can install stuff like wordfence and similar tools to continually scan your disk to look for 'infections', but... why allow those to be written to the drive in the first place? I know the answer is "convenience", but it's been a huge community price to pay.
- regecks 9y ago
  Can't reply to stephenr because comment thread is too deep, but it's perfectly possible to run WordPress without write permissions anywhere near executable code and then to schedule automatic updates at a different privilege level. Since this is done extremely rarely, that leads me to believe that its more of a cultural problem (perhaps with the WordPress team, even) than a technical one. Spent 5 years in shared PHP web hosting, can confirm that most of the people are muddling through with the bare minimum of understanding to get WordPress going.
  - stephenr 9y ago
    > schedule automatic updates at a different privilege level That is inherently not the default for wordpress, and at that point you may as well be installing via deb/rpm. I didn’t say scheduled updated are bad I said a self writable web app is a fucking security nightmare.
  - reificator 9y ago
    > Can't reply to stephenr because comment thread is too deep I've found that clicking a comment's timestamp to view a permalink to it will usually allow replying.
- temprature 9y ago
  > I would trust wordpress to keep their signing keys safe. What signing keys? Wordpress's automatic updates aren't signed, so your trust is horrendously misplaced. Someone already did the work for them to implement it[0], and rather than commit it, a Wordpress developer wrote a blogpost saying signing isn't really that important[1]. [0] https://core.trac.wordpress.org/ticket/39309 https://core.trac.wordpress.org/ticket/39309 [1] https://medium.com/@photomatt/wordpress-and-update-signing-51501213e1 https://medium.com/@photomatt/wordpress-and-update-signing-5...
mgkimsal 9y ago
I'd really like if WP offered an inbuilt way of doing installs/updates via ssh. defaults seem to require plaintext FTP credentials to itself. I know there was an ssh plugin, and I know it couldn't be the only option (or perhaps even default), but having it as an available option on install would still be nice...
- stephenr 9y ago
  I’m not sure that really improves the situation much. It’d still have effective write permission to itself. On shared hosting I’d have thought a user-account cronjob calling the app via cli (not via curl) could do the updates - but wordpress has always veered for “offer a shit solution to everyone” over “offer a secure solution to some subset of everyone”.
  - mgkimsal 9y ago
    by no means is it a big improvement, but it's forced me, on more than one occasion, to end up needing to enable an FTP server just to accommodate this behaviour. Just... more work (and increased insecurity, even if only for a small window of time). my default for wp installs is to just take write permission off everything all the time, then re-enable it when I know I will be doing something needing to write (updates, etc). There are likely some actual WP users who are not technical yet actually use the system to do their own content updates, but almost everyone I know who's using wordpress is managing it on behalf of their clients, doing all the content updates for them. These people could/should probably get familiar enough with ssh and stronger security practices, but the 'one click update' for themes/plugins/core seems to give a very strong (but ...problematic) sense of security.
- jlgaddis 9y ago
  You can always just grab a tarball, uncompress it locally, and then connect to the server with your favorite SFTP client to upload the new files to the server. It's not exactly elegant but it is possible. I did that more than once back in the good ol' days before the fancy schmancy automatic updates. After you do it a few times, though, you'll probably just give up and modify the file permissions so that WordPress can update itself at which point... If the user that WordPress (or the web server stack, I suppose) is running as has write permissions on the directory where WordPress lives, it can update itself directly without having to FTP to localhost or whatever. Of course, typically we'd say it would be a bad idea for the application to be able to do that but blah blah risk assessment blah blah trade-offs blah blah ... For a long while, this was a widely accepted/standard way of hosting multiple customers on a shared web server, using something like suexec+php-cgi or (even better, IMO) mpm-itk. Then, each customer's WordPress site would run under its own uid/gid in order to isolate them from one another. A single customer could break their own instance or allow it to get hacked over and over again, but at least it couldn't get to other users' sites. I'm not sure how the large shared web hosts are handling this nowadays or if anything has even changed. (Edit: After reading your other comments, mgkimsal, it's obvious that you already know all of this but I'm not going to delete/edit my comment now.)