Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache Web Server Bug Grants Root Access On Shared Hosting Environments (zdnet.com)

Posted by BeauHD on from the open-access dept.

An anonymous reader quotes a report from ZDNet: This week, the Apache Software Foundation has patched a severe vulnerability in the Apache (httpd) web server project that could --under certain circumstances-- allow rogue server scripts to execute code with root privileges and take over the underlying server. The vulnerability, tracked as CVE-2019-0211, affects Apache web server releases for Unix systems only, from 2.4.17 to 2.4.38, and was fixed this week with the release of version 2.4.39. According to the Apache team, less-privileged Apache child processes (such as CGI scripts) can execute malicious code with the privileges of the parent process. Because on most Unix systems Apache httpd runs under the root user, any threat actor who has planted a malicious CGI script on an Apache server can use CVE-2019-0211 to take over the underlying system running the Apache httpd process, and inherently control the entire machine.

"First of all, it is a LOCAL vulnerability, which means you need to have some kind of access to the server," Charles Fol, the security researcher who discovered this vulnerability told ZDNet in an interview yesterday. This means that attackers either have to register accounts with shared hosting providers or compromise existing accounts. Once this happens, the attacker only needs to upload a malicious CGI script through their rented/compromised server's control panel to take control of the hosting provider's server to plant malware or steal data from other customers who have data stored on the same machine. "The web hoster has total access to the server through the 'root' account. If one of the users successfully exploits the vulnerability I reported, he/she will get full access to the server, just like the web hoster," Fol said. "This implies read/write/delete any file/database of the other clients."

85 comments

  1. I got something you can root on by Anonymous Coward · · Score: -1

    Yeah, my DAMN balls

  2. 1996 called by Anonymous Coward · · Score: -1

    They want their technology stack back...

    1. Re: 1996 called by Anonymous Coward · · Score: 2, Informative

      Um apparently the internet didnt get that memo because apache is still the most popular webserver.

    2. Re: 1996 called by gweihir · · Score: 1

      Some people are fundamentally incompetent and clueless. To them new=better, which is pretty irrational.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re: 1996 called by Aighearach · · Score: 1

      Um apparently the internet didnt get that memo because apache is still the most popular webserver.

      That's not the presumed implication.

      The joke is, nobody uses a shared stack with a web config running as an apache module anymore. Each user on a modern shared system has their own virtualized private OS. Unix users and groups are good for managing the ownership of files between various partially-trusted users, but it is not a reasonable basis for any sort of serious security.

      Of course everybody is still running apache. But on the modern stack, you can only root yourself with this.

    4. Re: 1996 called by DamnOregonian · · Score: 3, Interesting
      You're mixing up shared hosting with a VPS. They are separate products, and both exist (I know, because my company sells both)

      With a VPS, obviously *you* can only root yourself, but more importantly, someone who has access to whatever the Wordpress exploit du jour is can root your VPS. Still problematic.

      The joke is, nobody uses a shared stack with a web config running as an apache module anymore.

      5 pinnocchios, right there.
      We host about 5000 domains on shared web hosting, and about 300 VPS instances.

    5. Re: 1996 called by Aighearach · · Score: 0

      5 shills, buddy. You're on slashdot talking shit... in defense of your work?

      Dude, like, shut the fuck up and get back to work, don't shill about your shitting 90s hosting service and how being a small hosting fish guarantees you're doing things right and that customers are benefiting by choosing you.

      Yeah fucking right! They should choose somebody who knows enough about the technology not to push old, insecure hosting stacks and then use false equivalency to try to create a scare about wordpress, as if using shitty shared hosting protects you from that or something. It doesn't. So if you use shitty wordpress, you get p0wned from that, in addition to already getting p0wned because you used shitty shared hosting without virtualization.

    6. Re: 1996 called by DamnOregonian · · Score: 1

      I don't think you know what the word shill means.

      There's so much wrong with your claims that I don't know how it doesn't embarrass you.
      You actually claimed that a VPS takes less resources than shared hosting. That's literally the stupidest fucking thing I've read today.
      Please, go on, enamor us with your wizardly computer science knowledge.

      You're a fucking idiot.

    7. Re: 1996 called by Aighearach · · Score: 1

      You don't fucking know, because your service is still using 90s tech. Why would you have any idea what the difference in resources is? That is a ghetto service level, you obviously didn't invest in a modern setup and then find that the old way was better.

      But I'll throw you a bone. VPS takes less resources because most of the instantiations are not actually in use most of the time. Containers not in use get parked, and transparently restored when you connect to them. It sounds "literally the stupidest fucking thing [you've] read" simply because it is true, and a technical detail. Of course it sounds stupid to you. You're providing 90s shared hosting, in 2019, and you're not only shameless, you're actually trying to shame others. Others who provide containerized services.

      My clients sure as fuck would rather have the safety of modern containers than the shit like in the story where anybody with half a clue who is hostile to your clients can p0wn your shit and attack them. When your clients are protected solely by hoping that the system doesn't have any undisclosed unix user escalation vulnerabilities, you're totally fucked at all times. That is how often that particular type of exploit has been in the wild continuously for decades. The user system is pretty good, for what it is, but it doesn't provide the protection needed for shared hosting. Duh.

    8. Re: 1996 called by DamnOregonian · · Score: 1

      You don't fucking know, because your service is still using 90s tech. Why would you have any idea what the difference in resources is? That is a ghetto service level, you obviously didn't invest in a modern setup and then find that the old way was better.

      LOL. Mmmmk.
      Being unable to disclose my employer, all I can say is that you have no idea what the fuck you're talking about.

      But I'll throw you a bone. VPS takes less resources because most of the instantiations are not actually in use most of the time.

      How irrelevant.
      A VPS has higher overhead, period. It's unavoidable.
      It requires splitting off the kernel namespace and adding more entries to the scheduler. It is literally twice as expensive to operate 2 apaches, than one. It is again, unavoidable.

      Containers not in use get parked, and transparently restored when you connect to them.

      Yes, and processes that are waiting on an accept() are also sleeping.

      It sounds "literally the stupidest fucking thing [you've] read" simply because it is true, and a technical detail. Of course it sounds stupid to you. You're providing 90s shared hosting, in 2019, and you're not only shameless, you're actually trying to shame others. Others who provide containerized services.

      No, it was the stupidest thing I'd read that day because it was not only factually incorrect, but logically incoherent. Everyone who reads your logic train is now stupider for having to try to figure out if there was any possible way you could be right.

      My clients

      Stop. They're customers, and they want fries with that.

  3. bad headline by Anonymous Coward · · Score: 0

    Phew, good thing this is only a problem on shared hosting environments. ðY'

    1. Re: bad headline by Anonymous Coward · · Score: 0

      We come in peace. We are not very drunk. Check out our scripts
      - local hacker user group

  4. Not all run it as root ... by kbahey · · Score: 3, Informative

    Because on most Unix systems Apache httpd runs under the root user, any threat actor who has planted a malicious CGI script on an Apache server can use CVE-2019-0211 to take over the underlying system running the Apache httpd process, and inherently control the entire machine.

    Well, on Ubuntu and derivatives, Apache does not run as root. It runs as the user www-data.

    So this applies to some Unix/Linux systems, not "most".

    --
    2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
    1. Re: Not all run it as root ... by Anonymous Coward · · Score: -1

      Who is retarded enough to run their web server as root????

    2. Re:Not all run it as root ... by Anonymous Coward · · Score: 0

      second that: on fedora and other red hat systems like centos, the web server runs under the apache user, not to mention some form of suexec.

      in addition, shared hosting is being replaced by vanity one-domain vm servers.

    3. Re:Not all run it as root ... by msauve · · Score: 1

      "affects Apache web server releases for Unix systems only"

      Linux != Unix. (although I suspect the summary is wrong). Does anyone run Unix these days?

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    4. Re:Not all run it as root ... by whoever57 · · Score: 1

      On most systems, the the worker processes run as "apache" or some other unprivileged user, but there is a parent process which still runs as root (you need root privileges to bind to port 80).

      --
      The real "Libtards" are the Libertarians!
    5. Re:Not all run it as root ... by Anonymous Coward · · Score: 1

      I thought the parent process was supposed to start up, bind port 80, then drop privileges before it started forking worker processes. By the time the worker processes are running there should be no root process to escalate to.

    6. Re:Not all run it as root ... by Wrath0fb0b · · Score: 4, Informative

      you need root privileges to bind to port 80

      Common sense would indicate that in that scenario you either

      • 1. Get the socket as early as possible in startup then setuid(2) yourself to a user with lower privileges (and chroot yourself, while you are at it) before answering any requests
      • 2. Failing that, run on a high numbered port and have iptables forward you traffic from 80, which is a specific instance of the more general strategy: run as little code as possible at high privilege

      What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.

      What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.

      What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.

    7. Re: Not all run it as root ... by Anonymous Coward · · Score: 0

      I'm as appalled. What should I do?

    8. Re: Not all run it as root ... by Anonymous Coward · · Score: 1

      Who runs their web server as root? Anybody who wants to run it on port 80. Apparently people here don't understand how it works. The base apache process starts up using the root user (which is required for opening a port below 1024 by the way) and then it creates subprocesses that run as 'apache' or 'www-data'.

    9. Re:Not all run it as root ... by hcs_$reboot · · Score: 1

      Well, on Ubuntu and derivatives, Apache does not run as root. It runs as the user www-data.

      Wrong. It starts as root, then forks as www-data for each request. https://muras.eu/2017/12/06/ap...

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    10. Re: Not all run it as root ... by ArchieBunker · · Score: 1

      I'm sure on modern bullshit distros like Ubuntu that systemd is involved somehow. That or some container nonsense.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    11. Re:Not all run it as root ... by Anonymous Coward · · Score: 2, Informative

      On most systems, the the worker processes run as "apache" or some other unprivileged user, but there is a parent process which still runs as root (you need root privileges to bind to port 80).

      Since both debian and redhat based systems do not work that way, and those groups are "most", you are not correct.

      The initial "parent" process runs as root only to bind to the ports, then drops privileged to a specified user (www-data, apache, whatever), and after that it launches the worker processes which load modules such as mod-cgid and mod-digest.

      While having root it isn't possible for CGI scripts to run. By the time it is possible there is no process in the chain that has any privileges above the specified UID.

      That doesn't make this CVE a non-threat, but the threat isn't to the full system, just everything related to hosting.
      On a shared web host you can still manipulate other users files which the web server can access.

      Possibly the primary virtual-host as well depending if those files are editable by www-data or are read-only to all but root. That would also possibly limit system provided CGI scripts, as those are typically 755 root:www-data
      But I have seen installations where even /var/www is fully owned by www-data and would be at risk.

      Any database would probably be at enough risk for it to not matter.
      There is little difference between full root to the SQL server, and having the user credentials for each and every user database within, at least if you intend to copy or delete the data.
      The attacker may be unable to manipulate credentials (IE add/remove accounts), but since they would have the credentials used by the user scripts that would be little comfort to everyone else.

    12. Re: Not all run it as root ... by Anonymous Coward · · Score: 1

      Don't knock it. I use Ubuntu to run my apache snap inside my systemd snap all running on a Docker snap for good measure. Anyone not doing it this way is a dinosaur on a fast track for the unemployment queue.

    13. Re: Not all run it as root ... by jrumney · · Score: 1

      Its trivial to redirect port 80 to a non-privileged port using iptables, so even the base process has no reason to be running as root.

    14. Re:Not all run it as root ... by whoever57 · · Score: 1

      Since both debian and redhat based systems do not work that way,

      I find it so funny when morons "correct" me.

      From a CentOS 7 system:
      $ sudo service httpd start
      [sudo] password for .....:
      Redirecting to /bin/systemctl start httpd.service
      $ ps -Af | grep [h]ttpd
      root 21827 1 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
      apache 21829 21827 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
      apache 21830 21827 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
      apache 21831 21827 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
      apache 21832 21827 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
      apache 21833 21827 0 22:47 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND

      See that first process (PID 21827) : it's running as root.

      --
      The real "Libtards" are the Libertarians!
    15. Re:Not all run it as root ... by Aighearach · · Score: 1

      Personally, I'd rather have one process running as root than to have a hard requirement to start up a process as every possible user that could own a process.

      It is sad the state of technical knowledge on slashdot these days. There was a time when a random slashdot cowherd was expected to understand the basics of system administration!

    16. Re:Not all run it as root ... by whoever57 · · Score: 1

      This isn't new.

      Some years ago, I had some moron disputing the way a fresh installation of mysql started on CentOS/RedHat. The moron accurately described how things work on Debian (and Debian-derived distros), but, even though I pasted the exact commands and responses from a CentOS system that showed my point, the moron kept disputing it.

      --
      The real "Libtards" are the Libertarians!
    17. Re: Not all run it as root ... by TheRaven64 · · Score: 2

      That's a terrible idea in a multi-user environment, because when the Apache process dies any other user can open that port (they may even open it accidentally) and now they get all of your web server traffic.

      On modern UNIX systems; however, it is possible to grant the permission to open specific low ports. For example, on FreeBSD the portacl MAC framework policy can control this. On Linux SELinux can do the same thing.

      --
      I am TheRaven on Soylent News
    18. Re:Not all run it as root ... by DamnOregonian · · Score: 3, Interesting

      You're killing us, smalls.

      Apache's parent process always runs as root.
      This is so that it can spawn the necessary privileged ports.
      Only children in fork/pre-fork models run as the unprivileged user, which is precisely what this CVE is about.
      Unprivileged fork/pre-fork workers that have had their code compromised can fuck with the scoreboard (chunk of shared memory between privileged parent, and unprivileged child) and get the privileged parent to run worker-supplied code before privilege drop after the fork.

    19. Re:Not all run it as root ... by DamnOregonian · · Score: 4, Informative

      What's not an answer is "run the actual process as root while serving user requests".

      Good thing that's not what's happening here.

      It's shocking that this is even considered remotely like a possible solution.

      It's also shocking when people offer an uninformed opinion.

      or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC.

      This is the funniest quote here, because that's exactly how apache works.

      What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.

      The vulnerability here is in how the privileged parent process handled IPC with the unprivileged children. IPC between privileged and unprivileged processes is always dangerous without formal verification and lots of eyeballs making sure you parse that IPC safely.
      They got bit here. They fixed where they got bit.

    20. Re:Not all run it as root ... by DamnOregonian · · Score: 3, Interesting

      Ya, the dude who "corrected" you is fucking insane.
      No version of apache has code that drops the privs of the master process, only the workers.
      It fundamentally breaks operations like HUPs (lest you decide that you want your apache configs readable by the workers.)

    21. Re: Not all run it as root ... by DamnOregonian · · Score: 1

      Wait, are you telling me he didn't just prove that there's no reason for ports to be privileged?! /sarcasm.

    22. Re:Not all run it as root ... by DamnOregonian · · Score: 1

      Linux is very close to a UNIX.
      Deployed actual UNIX systems that run apache are irrelevant, statistically.

      They meant *nix.

    23. Re:Not all run it as root ... by Wrath0fb0b · · Score: 1

      And why didn't the Apache shim call setuid to remove its root privileges after doing what it needed to do?

      I get that IPC across privilege boundaries is hard. You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.

    24. Re:Not all run it as root ... by DamnOregonian · · Score: 1
      It didn't call setuid, because it is designed to be a privileged process. This is to facilitate certain features of the program that can not be achieved otherwise.
      First off the top of my head, is graceful HUPs. Only a privileged process may bind sockets to listening ports, or read privileged files, meaning absent a privileged master process, you have to completely respawn the process (and incur the downtime of it re-reading its configs, certificates, etc.)

      You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.

      I don't see how punting the secure privilege-crossing processing up a layer (to the kernel) is any more pragmatic. Especially if it requires sacrificing functionality of the program. In fact, I'd argue a more privileged master process is in fact the more pragmatic approach.

    25. Re:Not all run it as root ... by Wrath0fb0b · · Score: 1

      Only a privileged process may bind sockets to listening ports, or read privileged files

      OK, but those sockets can be bound and those files read before dropping privileges. Those things should be considered fixed for the lifetime of the process anyway.

      meaning absent a privileged master process, you have to completely respawn the process

      In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change the configuration of a daemon on the fly instead of just reloading it?

      I don't see how punting the secure privilege-crossing processing up a layer (to the kernel) is any more pragmatic.

      The principle of least privilege is real. There has to be security surface area in the kernel, no need to just add to the attack surface unless it's absolutely necessary for a critical function.

    26. Re:Not all run it as root ... by DamnOregonian · · Score: 1

      OK, but those sockets can be bound and those files read before dropping privileges.

      Yes, we know. You can't undrop your privileges, though.

      Those things should be considered fixed for the lifetime of the process anyway.

      As I tried to explain, that's where you, and the designers of most of the services that run the web (apache, nginx, postfix, etc) disagree.

      In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change the configuration of a daemon on the fly instead of just reloading it?

      A proposal? It's the status quo... You're the one presenting proposals here. I'm the one explaining why they've been rejected.

      The principle of least privilege is real. There has to be security surface area in the kernel, no need to just add to the attack surface unless it's absolutely necessary for a critical function.

      Ah yes, but we were discussing pragmatic approaches, weren't we? Don't use ideals and principles in a discussion about pragmatism, it's means you've lost right out the gate.

      Ignoring that, of course the principle of least privilege is real. At the same time, so is the principle of least downtime. And the principle of most flexibility.

  5. Good job open source by Anonymous Coward · · Score: -1

    You fucked it up again.

  6. Apache? by hcs_$reboot · · Score: 1

    Not everyone is using nginx nowadays?

    --
    Slashdot, fix the reply notifications... You won't get away with it...
    1. Re:Apache? by Anonymous Coward · · Score: 0

      Not everyone is using nginx nowadays?

      Most (or at least a lot of) people running nginx are just proxying traffic on to apache.
      Realistically, modern apache with event and php-fpm make bothering with nginx sort of redundant.

    2. Re:Apache? by Anonymous Coward · · Score: 0

      If nginx supported httpd-style access control formats (ie handled .htaccess files) it would likely be a different story. Too many projects used in too many places which relied on included .htaccess files for security (prevent script execution of files in specific directories) and SEO rewrite practices.

    3. Re:Apache? by MatthiasF · · Score: 2

      Using .htaccess is bad practice anyway. Besides the security implications, it's also inefficient to check every folder for the file when it is browsed.

      Better to redirect to a different webserver for 404s that can lookup the URL for broken links and send you back to the right URL, then create hundreds or thousands of .htaccess files.

    4. Re:Apache? by Anonymous Coward · · Score: 0

      Ehh, for a long time I was using mpm-event because adding a proxy seemed like too much effort. Recently I caved and switched to nginx as the front end... it was night and day.

    5. Re:Apache? by hcs_$reboot · · Score: 1

      Better to redirect to a different webserver for 404s that can lookup the URL for broken links and send you back to the right URL, then create hundreds or thousands of .htaccess files.

      It's a fucking than. Newbies who read your post will create these garbage .htaccess crap files.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    6. Re:Apache? by CODiNE · · Score: 1

      Assuming you don't create an XSS vulnerability with the redirect forwarding server.
      If they can't get this much right....

      --
      Cwm, fjord-bank glyphs vext quiz
    7. Re:Apache? by Aighearach · · Score: 1

      People that want a thinner front end use Apache Traffic Server these days.

      And before that, you just learn how to write an apache config file and turn off what you don't use, and suddenly it is fast. ;)

    8. Re:Apache? by TheRaven64 · · Score: 1

      If you're using php-fpm, why bother with Apache? Nginx configuration for that scenario is a lot simpler.

      --
      I am TheRaven on Soylent News
    9. Re:Apache? by DamnOregonian · · Score: 1

      Well, they use it as a really fast proxy to a web server that doesn't suck, yes.
      That doesn't really address this problem, though.

    10. Re:Apache? by DamnOregonian · · Score: 1

      Besides the security implications, it's also inefficient to check every folder for the file when it is browsed.

      :|

      I don't know what else to say to that. Of the dozens of syscalls that are performed on a single request, the fstat(.htaccess) for the path components aren't the painful ones. particularly because those dnodes are likely cached by the VFS.

      Better to redirect to a different webserver for 404s that can lookup the URL for broken links and send you back to the right URL, then create hundreds or thousands of .htaccess files.

      Ya, that's one pretty egregious example of using the wrong tool. I agree you shouldn't use a .htaccess where a .htaccess isn't well suited.
      You probably shouldn't also assume that all scenarios suffer the pitfalls of the worst-case.

      Is systems administration dying?

  7. Root? by Anonymous Coward · · Score: 0

    I've never seen apache running as root.
    I guess working at data center for the last decade doesn't make me any kind of expert or anything though.

    1. Re:Root? by Anonymous Coward · · Score: 0

      Yeah? Do you listen on port 80 or 443? If you do then you probably start it as root.

    2. Re: Root? by Anonymous Coward · · Score: 0

      I guess you arent an expert then if you don't understand how the process model works.

    3. Re:Root? by Aighearach · · Score: 1

      I've never seen apache running as root.
      I guess working at data center for the last decade doesn't make me any kind of expert or anything though.

      Nope. "Working at a data center" does not "make [you] any kind of expert or anything."

      Being competent enough to have already RTFM would imply that you may be at least minimally competent. But the manual would explain a wide variety of circumstances that leave you with a root process that is used to spawn more processes. If you were an expert you'd already have used all that stuff in all the different configurations, from one BOFH to the next. And you'd also know that under the most common usage scenarios, there is a root process.

      You probably don't even have root on those machines.

    4. Re:Root? by DamnOregonian · · Score: 1

      It apparently really didn't.
      Though to be fair, we hire lots of people who work in our datacenters who don't know the word root from the holes in their asses.
      Someone's gotta sweep the floors.

  8. bullshit scare by Anonymous Coward · · Score: 1

    Anybody running Apache these days is running Apache as its own user ("www" or "apache" depending upon your flavor of Unix). So this really is not an issue with 99% of most web servers. If you're running Apache as root, you're an idiot.

    1. Re: bullshit scare by Anonymous Coward · · Score: 0

      Omg! So much ignorance in this forum these days!

    2. Re:bullshit scare by Aighearach · · Score: 1

      The real reason it not an issue with over 99.999% of web servers is that few people are still using 90's style shared servers with no virtualization or sandboxing.

      If you're using a cheap web server that is protected merely by the unix user controls, my goodness, you should shop around. Seriously. Are you really really really sure that you need a webserver, but can't afford $5/month for a VPS?

      In 1998, you might have to subject yourself to that if you wanted the price that low. But virtualization lowers the costs for the operator, so the price curve inverted long long ago.

    3. Re:bullshit scare by DamnOregonian · · Score: 3, Interesting

      Quit saying this. It simply isn't true.

      Your logic that you're using to justify this false claim isn't bad logic, it's just incomplete.
      Why do people take shared hosting over a VPS? Simply because the control panel is simpler to operate.
      Our shared hosting customers are often people with some family website or other personal website.

      The shared-hosting market is fucking *huge*.

    4. Re:bullshit scare by Aighearach · · Score: 1

      Why do people take shared hosting over a VPS? Simply because the control panel is simpler to operate.

      This isn't just wrong, it is dangerously stupid and ignorant.

    5. Re:bullshit scare by DamnOregonian · · Score: 1

      I'll take baseless claims for 100, Alex. Being you have already argued that 99.anything% of the virtualized hosting market is of the VPS model, you clearly have no fucking idea what you're talking about.

  9. Stop using open source server software!!! by Anonymous Coward · · Score: -1

    Since anyone can modify source code of open source software, is it really hard to guess that, all commonly used open source software, must be full of intentionally created SUPERBUGS, to be used as secret backdoors???

    1. Re:Stop using open source server software!!! by Aighearach · · Score: 1

      When it requires already having a user account on the server, it isn't really a secret backdoor. It is more like kicking in the door of the server cage next to you; they're going to know who did it.

    2. Re: Stop using open source server software!!! by cyber-vandal · · Score: 1

      Yeah there's no way to be anonymous on the internet.

    3. Re:Stop using open source server software!!! by DamnOregonian · · Score: 2

      This bug does not require a user account on the server at all. It does however require a second bug to work, as in an exploit in PHP or some other module that allows modifying the shared memory segment between the workers and the master.

      It's a pretty difficult vulnerability to exploit, really. It requires:
      1) some badly written php or something else that will either allow you to eval() client submitted code, or write it to disk and then request it.
      2) an exploit within the php (or equivalent) interpreter itself to allowed direct memory modification of Apache worker IPC shared data segment (Scoreboard).
      3) an eventual graceful restart of apache (probably next time logrotate runs)

    4. Re:Stop using open source server software!!! by Aighearach · · Score: 1

      I'm not sure the hairs you're splitting were quite wide enough to be split.

    5. Re: Stop using open source server software!!! by Aighearach · · Score: 1

      Don't forget to include a comment with your comment next time.

      And also, is the situation "on the internet" or "when spending money electronically?" Are those automatically the same thing?

      We know you don't know, and don't have any thoughts, because you'd have included at least one thought in your comment.

    6. Re:Stop using open source server software!!! by DamnOregonian · · Score: 1

      I'm pretty sure I'm more qualified to opine than you are. I have already written a POC for this exploit. I have my own CVE.
      If you've read slashdot long enough, you've actually read about it.

      I was splitting hairs, I was correcting a very incorrect assertion on your part.

    7. Re: Stop using open source server software!!! by cyber-vandal · · Score: 1

      Yeah there's no way to be anonymous on the internet.

  10. Mac OS is certified UNIX (tm). Solaris. See BSD by raymorris · · Score: 2

    > Does anyone run Unix these days?

    Yes, Mac is Unix. Not Unix-like, but actual UNIX (tm).

    BSD (Berkeley Standard Distribution) used to be called Berkeley UNIX. It *was* UNIX, and the Unix hasn't been entirely removed. Some of the original Unix code was oown source and FreeBSD was built with that open source portion of Unix at it's core. Since then, UNIX and the BSDs have evolved separately, of course.

    Solaris is real UNIX.

    So yeah, all those MacBooks are running UNIX. It's pretty handy to have a UNIX that is approved and supported by corporate IT departments.

    1. Re:Mac OS is certified UNIX (tm). Solaris. See BSD by msauve · · Score: 1

      "Yes, Mac is Unix."

      Last I knew, they ran a Mach kernel. When did that change to a UNIX/ATT one?

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
  11. Debian by Anonymous Coward · · Score: 0

    Because on most Unix systems Apache httpd runs under the root user, any threat actor who has planted a malicious CGI script on an Apache server can use CVE-2019-0211 to take over the underlying system running the Apache httpd process, and inherently control the entire machine.

    Well, on Ubuntu and derivatives, Apache does not run as root. It runs as the user www-data.

    So this applies to some Unix/Linux systems, not "most".

    You started too far down the tree. Debian also uses www-data

  12. 3,700 pages of detailed requirements define Unix by raymorris · · Score: 3, Interesting

    The Mac OS *kernel* comes from AT&T via DEC and others. Anyway, thirty years ago, AT&T sold the Unix name, and 25 years ago it was transferred to the Open Group, so it's been 30 years since Unix and and AT&T parted ways, 25 years since the Unix name went open. The reason I say "the Unix name" is because when the name was originally sold and locked down, there were several different Unix operating systems. At least three, which were all Unix, all derived from the same code. One group kept the name, the Open Group via AT&T and Novell.

    In other words, it's kinda like asking "is Sierra actually Mac? I didn't know know Wozniak wrote it." Yes, new programmers can work on some software and it's still real. There have been 30 years of programmers between AT&T and modern Unix. It's still Unix.

    There is a 3,700 page set of detailed specifications called the Single Unix Specification. A Unix system is defined as an operating system which is certified to meet all of those specs. The spec includes things like a Bourne-shell derived /bin/sh called the POSIX shell, ncurses, and 1,123 kernel and library functions.

    Note the Unix spec describes (in detail) what a Unix *operating system* is, how it behaves and what it provides. Less than half of the spec deals with the *kernel*. The specs say the operating system must provide all of these different functions, which must work exactly as described. It does not specify *who* must write the functions. That's been true for 25 years. The pedigree of the kernel does not matter at all in terms of whether it's Unix. If you and I wrote an exact copy of Solaris Unix, so we ended up with the same operating system, that would be a Unix, if we got it certified showing we made a faithful copy - we met all specs correctly.

    As far as the pedigree of the *kernel* goes, back in the AT&T days, AT&T licensed DEC, Microsoft, and others to create Unix systems. There were three major Unix systems. OSF/1 was one of those, BSD was another. OSF/1 (Open Software Foundation 1) used a modified version of a kernel built, for Unix systems, based on BSD Unix code, called mach. Years later, more code from BSD, mach, and other sources in the NeXTSTEP operating system. When Apple bought Next, they replaced much of the kernel code from NextSTEP with code from a different, more direct, descendant of OSF, which had been renamed OSFMFK, then modified it extensively to create XNU.

    So yes there is some mach code in XNU. Mach was largely a reworking of kernel code from the Berkeley UNIX tapes. All of these kernels were designed for, and used in, Unix systems.

    A list of Unix (tm) operating systems can be found here:

    https://www.opengroup.org/open...

  13. Re:3,700 pages of detailed requirements define Uni by DamnOregonian · · Score: 2

    Less than half of the spec deals with the *kernel*

    Technically speaking, the SUSv3, which OSX on Intel procs conforms to, doesn't specify kernel functionality at all. It does specify "system interfaces", but they can be handled by an entirely user-space libc layer.
    This is why Linux kernel based operating systems have been SUSv3 certified as well.

  14. Well at least I know we aren't affected by this by Anonymous Coward · · Score: 1

    ... as our apache instances are much much older than the affected versions. Phew! :')

  15. True. I started to mention that by raymorris · · Score: 1

    Yeah I started to say "system interfaces, which can be provided by the kernel or libraries", but that paragraph was long enough already.

    It would be rather difficult to make a Unix system using a kernel that wasn't designed to be at least Unix-like, though. You'd probably end up with either emulation or at least something like Wine, it would be non-native. The Linux kernel and the typical Unix system is designed to be like Unix, and therefore it's easy enough to make a Linux system comply.

    1. Re:True. I started to mention that by DamnOregonian · · Score: 1

      I definitely agree that a kernel that was designed to be mostly POSIX compliant (*BSD, Linux, etc.) requires far less lifting from its libc to reach full compliance, but I will argue that just because a Kernel that doesn't natively support POSIX certain POSIX functionalities (Let's say, for example, named pipes) that implementing them in a libc is any less native.
      This is the case in just about every *nix, even OSX.
      In OSX, for example, pselect() is implemented on top of select().

    2. Re:True. I started to mention that by raymorris · · Score: 1

      I don't know enough about the topic to say much more intelligently. My name is in the kernel changelog only once.

      I do notice that all Lamborghini Countach kit cars are built on Fieros, none are built on on VW bus, or a Corolla. As you said, it's much easier when the source is like the target in basic structure.

      As to native, I suppose it also depends to some extent on the native source environment. If you had a true micro-kernel, perhaps in an academic setting, putting a lot of functionality in libraries would be "native", it would be the standard way to do things on that platform. On the other hand, if you were starting with a monolithic system with no networking, no concept of sockets, any userspace implementation of pselect would probably be quite foreign.

    3. Re:True. I started to mention that by DamnOregonian · · Score: 1

      I was thinking more along the lines of WSL/Cygwin/POSIX Subsystem for Windows.
      The fact that (near) POSIX compliance is offered by Cygwin's libraries doesn't make it emulated, any more than OSX implementing (emulating?) pselect inside of libc on top of the kernel's select.
      My name is not directly in the kernel sources, I do however have a CVE for a Linux kernel exploit, a bionic userspace exploit, and my name is on several jailbreaks of the early iPhones, and I am, AFAIK, the first person to ever break the firmware RSA signature protection on a cell phone (V3 RAZR), though I don't suspect any of that makes me more qualified as to what seems to be a largely philosophical question.
      Perhaps we just have different perspectives on what's truly foreign.

    4. Re:True. I started to mention that by raymorris · · Score: 1

      > several jailbreaks of the early iPhones ... The first person to ever break the firmware RSA signature protection on a cell phone (V3 RAZR)

      That's very cool. I've worked in security for many years, and I have a pretty good understanding of cryptography, but always from a defensive standpoint. I very, very rarely break anything. Do you happen to have a write up of how you want about doing that, in a practical sense?

      Over 90% of my time thinking about how people might break things is theoretical, what one theoretically could do. How you'd actually break that RSA signature would be very interesting to me.

      > I was thinking more along the lines of WSL/Cygwin/POSIX Subsystem for Windows.
      The fact that (near) POSIX compliance is offered by Cygwin's libraries doesn't make it emulated

      Not emulated, we know what Cygwin stands for. If someone says "native Windows APIs", they probably aren't talking about Cygwin. :) So neither emulated not native to that system.

    5. Re:True. I started to mention that by DamnOregonian · · Score: 1

      Original Forum Post
      People posting writeups of how to use it a year later
      I actually never did do a write-up of this particular exploit, so this is a first. It was also while I worked fast food, and before I had any idea how professional technical world worked, so I didn't ever make source available either. I was 23 at the time. My later work was much better and more publicly documented.

      Well, I didn't break RSA's encryption, of course. I'm no mathematician or cryptanalyst.
      But back in 2006, RSA signed firmware images (for phones at least) was in its infancy, and there weren't a lot of people attacking them, so a lot of mistakes were made.
      In the case of the RAZR, the ARM7 in it was attached to some NOR flash, and had some mask rom on the CPU.
      The mask rom had the exception vectors pointed to the main firmware of the device.
      Older versions of the phone had a bootloader that was not protected, and allowed arbitrary reads from memory space, so I was able to get a dump of address space of the device by borrowing a friend's phone.
      One could flash the main firmware without signature on the newer bootloader, but it wouldn't execute if it wasn't valid.
      The bootloader was simple, and required sending of a binary payload (called a RAM downloader) to initiate the actual flashing process. This payload also needed to be signed for the bootloader to execute it.
      The RAM downloader payload had a pointer within it pointing to the signature. The validity of this pointer was not checked.
      This means that I have control of the access violation exception vector (since it pointed to flash that I could write, but not execute), and the ability to trigger an access violation (because pointer to the signature for the RAM downloader was not checked), all within unsigned code (even if I can't execute it during the normal boot process)
      I then wrote a small program to relocate a modified RAM downloader (just offset long references) to the position in the firmware that would be jumped to when an access violation happened.
      With the modified bootloader in place, and able to be executed, I was able to overwrite the main bootloader with one from an earlier firmware load of the phone that did not have signature verification.

      This was actually my first time using an ARM processor, and they didn't really have tools widely available for working with them. I did my reverse engineering, as well as my modifications to the unprotected exploit bootloader with the actual ARM docs. It was also my first time dealing with assembly language at all. I'd say deciding I was going to free that phone changed my life. Since then, I have made tons of money breaking security in other phones, been offered to speak at national conferences, and offered jobs as a security researcher. I guess I developed a passion for freeing the hardware I had purchased from shithead companies that tried to lock us out of them.

    6. Re:True. I started to mention that by raymorris · · Score: 1

      Very cool, thanks for explaining that. Makes sense. Doing it as an exception was clever.

      > This was actually my first time using an ARM processor, and they didn't really have tools widely available for working with them. I did my reverse engineering, as well as my modifications to the unprotected exploit bootloader with the actual ARM docs.

      You're not easily intimidated are you? :)

  16. Open Sores fail #20972309304823 by Anonymous Coward · · Score: -1

    Yet another HILARIOUS failure of the open sores development model. And STILL the libtards on slashdot will tell us that its better than closed source, despite all the FACTS and EVIDENCE that goes aganst there religious belief.

  17. Obviously time for me to sleep by raymorris · · Score: 1

    As I was drifting off to sleep I wrote:

    > Not emulated, we know what Cygwin stands for.

    As I was writing "Cygwin", half my brain was apparently thinking "Wine". *Wine* is not an an emulator. Lol.