Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Programming Security

Drupal Warns of New Remote-Code Bug, the Second in Four Weeks (arstechnica.com) 50

For the second time in a month, websites that use the Drupal content management system are confronted with a stark choice: install a critical update or risk having your servers infected with ransomware or other nasties. From a report: Maintainers of the open-source CMS built on the PHP programming language released an update patching critical remote-code vulnerability on Wednesday. The bug, formally indexed as CVE-2018-7602, exists within multiple subsystems of Drupal 7.x and 8.x. Drupal maintainers didn't provide details on how the vulnerability can be exploited other than to say attacks work remotely. The maintainers rated the vulnerability "critical" and urged websites to patch it as soon as possible.
This discussion has been archived. No new comments can be posted.

Drupal Warns of New Remote-Code Bug, the Second in Four Weeks

Comments Filter:
  • by TheZeitgeist ( 5083373 ) on Wednesday April 25, 2018 @04:11PM (#56502191)
    Apparently, the source is open more ways than one.
  • by Billly Gates ( 198444 ) on Wednesday April 25, 2018 @04:18PM (#56502221) Journal

    Drupal and php are so well secured and up to date that this can happen is simply inconceivable

    • Re: (Score:3, Funny)

      by Narcocide ( 102829 )

      Drupal and php are so well secured and up to date that this can happen is simply inconceivable

      You keep using that word... I do not think it means what you think it means.

    • by goombah99 ( 560566 ) on Wednesday April 25, 2018 @04:42PM (#56502343)

      Why don't developers just write code that doesn't have security holes in it?

      Presumably because they can't. It's time we started programing computer resource sandboxes into every application by default.

      Linux and Mac, and Windows all have things for this. Macs have a dtrace based sandbox that can be per application or per process.

      sandboxes can specify what a process and all child processes can do at the computer resource level. Can they get on the network? Can they access the file system? what files can they access? do they have write permission? how much memory can they use? how much cpu? and so on.

      If we always launched processes with these clamped down a lot of security holes would not be exploitable. Why is it these are largely unused?

      • by Njovich ( 553857 )

        What's the point of that when the real sensitive data is in the website? The PHP code still has to access the database. Who cares about anything else? Either way, it's pretty standard practice these days to run sites in a separate VM or otherwise sandboxed environment.

      • You mean like containers that Linux and Amazon use and very recently Windows and Azure Linux/Windows serverless [arstechnica.com]?

        Problem is it doesn't solve SQL access bugs even if you can generate another container the data is still compromised

        Kids today use node.js and frameworks from Azure and Amazon that are secured and unfortunately locked to these platforms.

        Coders should not be security experts. The frameworks should which PHP has shown are not written by such

      • Why do people use php?

        • Why do people use php?

          Same reason they use python - you don't need to be aware of much to get results. In reality, there is very little difference between python and php other than (around) a 200:1 ratio of code in the field and that php is almost exclusively found in world-facing code and python isn't.

    • fyi: saveie6.com yields 404

    • by Torvac ( 691504 )
      unpossible
  • the open-source CMS built on the PHP programming language

    • it does seem PHP panders to low-talent and lazy developers who make all manner of insecure platforms and modules. A developer who decides to go into PHP is much like a person who joins the band to play the triangle.

      • by Anonymous Coward

        PHP is my go-to language of choice long before Python, Ruby, Go, NodeJS, Rust, Perl, D, C++, etc. It's a superior platform in the hands of someone who knows what they are doing. No language out there *natively* comes close to touching the power, flexibility, and performance of PHP arrays, which are the ultimate data structure with near-O(1) insert, update, delete, and find operations that keeps the order of elements: The hash table + linked list solution to data management is, quite frankly, brilliant.

        On

        • Nonsense, a company running those multiple systems will have the PHP ones broken into early and often. Web application firewalls will have the most rules devoted to php flaws and exploits. It is the insecure malware ridden choice, and the low wage developers are the ones who work on it. in short, it panders to low watt bulbs and is an attack and malware magnet.

  • I'm getting awfully nostalgic for the security addled PHPNuke right now. Reminds me of the good old days when even basic user data sanitatizaton seemed to be considered an excessive novelty.

    Perhaps "good old days" is not the best way to describe it, actually.
  • The original bug was a way to compose query string parameters (the part of the URL after the ?) that permitted injecting executable code in a form. The new bug is a variation where the malicious query string is part of a redirect URL passed through the query string, so it doesn't get filtered with the previous patch, because it has escaped characters. So it's not really a new bug, but rather plugging an oversight on the original patch.

    On the positive side: Drupal has security audits of its core and 3rd part

Who goeth a-borrowing goeth a-sorrowing. -- Thomas Tusser

Working...