Were DreamHost-hosted servers vulnerable to the log4j vulnerability, and if so, have they been patched?

If they were vulnerable (e.g., if they included the logging tool by default), I hope it’s been patched across the board.

See:

I can’t say for sure, but looking through the packages and files on Shared Hosting (dpkg -l and find / -ipath '*log4*'), I don’t see any Java Log4j installed, although there is a Perl version installed (liblog-log4perl-perl).

It seems unlikely that the Perl version has the same vulnerable, and the source package hasn’t been changed recently.

Thanks, that’s somewhat reassuring. (Though that just shows it’s not there now—no word yet on whether it was there on Thursday or Friday. And I hope you’re indeed right that the Perl port probably doesn’t have the same or a similar vulnerability.)

If someone on shared hosting did install log4j on their own account subdirectory for themselves, there isn’t any further privilege escalation aspect to this particular bug, is there? That is, it’d only be that one DH account in danger, not other accounts on the shared server, because it would be running at their account level… correct?

Due to paranoia/OCD/geekiness, I have a daily cron job that diffs the output of dpkg -l against the previous day (it’s nice to know how the sand is shifting under one’s feet). FWIW, I haven’t seen any log4j or related changes in the past weeks. Of course, DH has many other systems beyond the front-line hosting servers (DB, Mail, Admin, etc), so it’s impossible to know if any of them use log4j.

I think you’re right, the damage would probably be limited to the one shell account (note, this opinion is based on my extensive research – i.e. mostly reading HackerNews comments! :-)

Thanks, Habilis. Nice idea of the daily diff. I might copy that idea.

Good point also, though, about the possibility of other systems, beyond customer examination, being vulnerable. Hopefully DH rushed to check those for the package when this news hit, or hopefully any systems were immediately patched with that setting-flipping update when it came out. (And if any such DH system did have it installed, hopefully it wasn’t among targets exploited in the wild before that.)

When vulnerabilities like this come up, It’d be reassuring to hear some confirmation from DH via something like @dhstatus that no systems of their’s were vulnerable, or if any were, their timeline of addressing it.

Sorry if I sound over-worried, but in part due to a past device compromise experience, news like this gets me a bit anxious…

In the last week or so, I’ve started to see log hits related to the Log4j exploit. Most are showing up in the User-Agent string, for example:

X.X.X.X - - [13/Dec] "GET /api HTTP/1.1" 404 0 "-" "${jndi:ldap://...}" 

Interestingly, DH’s ModSecurity setup is rejecting most of the hits. DH appears to have added a specific rule on the 16th, but most hits are being rejected by more generic rules (like Remote-Command pattern match). Here’s DH’s new rule:

/dh/apache2/template/etc/mod_sec3_CRS/99_dreamhost_rules.conf:
SecRule REQUEST_HEADERS:User-Agent "^ **jndi** :ldap$" "phase:1,id:1990115,log,auditlog,deny,msg:'Log4j2 exploit crawling'"

Of course, the exploit requests are still being logged (double-logged for ModSec blocks), so there is the danger that someone might later feed the logs into a program that uses Log4J! Log attacks are tricky – now after grep-ing thru my logs, I wonder if grep has any 0-days I should worry about… :slight_smile:

Also of note:

The Java packages on my shared DH server got updated yesterday. Based on the Ubuntu security notice, the update doesn’t seem to have anything to do with Log4J, but it is nice to know that holes are being patched (dpkg -l diff below).

--- /home/user/.cache/notice-packages	2021-12-18 00:00:01.877213597 -0800
+++ /home/user/.cache/notice-packages.new	2021-12-19 00:00:02.339417121 -0800
@@ -1693,10 +1693,10 @@
 ii  open-iscsi                                  2.0.874-5ubuntu2.10                             amd64        iSCSI initiator tools
 ii  open-vm-tools                               2:11.0.5-4ubuntu0.18.04.1                       amd64        Open VMware Tools for virtual machines hosted on VMware (CLI)
 ii  openipmi                                    2.0.22-1.1ubuntu2.1                             amd64        Intelligent Platform Management Interface (for servers)
-ii  openjdk-8-jdk:amd64                         8u292-b10-0ubuntu1~18.04                        amd64        OpenJDK Development Kit (JDK)
-ii  openjdk-8-jdk-headless:amd64                8u292-b10-0ubuntu1~18.04                        amd64        OpenJDK Development Kit (JDK) (headless)
-ii  openjdk-8-jre:amd64                         8u292-b10-0ubuntu1~18.04                        amd64        OpenJDK Java runtime, using Hotspot JIT
-ii  openjdk-8-jre-headless:amd64                8u292-b10-0ubuntu1~18.04                        amd64        OpenJDK Java runtime, using Hotspot JIT (headless)
+ii  openjdk-8-jdk:amd64                         8u312-b07-0ubuntu1~18.04                        amd64        OpenJDK Development Kit (JDK)
+ii  openjdk-8-jdk-headless:amd64                8u312-b07-0ubuntu1~18.04                        amd64        OpenJDK Development Kit (JDK) (headless)
+ii  openjdk-8-jre:amd64                         8u312-b07-0ubuntu1~18.04                        amd64        OpenJDK Java runtime, using Hotspot JIT
+ii  openjdk-8-jre-headless:amd64                8u312-b07-0ubuntu1~18.04                        amd64        OpenJDK Java runtime, using Hotspot JIT (headless)
 ii  openssh-client                              1:7.6p1-4ubuntu0.5                              amd64        secure shell (SSH) client, for secure access to remote machines
 ii  openssh-server                              1:7.6p1-4ubuntu0.5                              amd64        secure shell (SSH) server, for secure access from remote machines
 ii  openssh-sftp-server                         1:7.6p1-4ubuntu0.5                              amd64        secure shell (SSH) sftp server module, for SFTP access from remote machines
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.