bshipp · HackerTrans

The people who are crashing their 600HP Linux systems are, unfortunately, not the ones who are reading CVE listings in their spare time. Canonical and other distros are probably going to have to patch that default setting.

bshipp

2 年前議論

Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration.

  > "This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure . Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices. This file contains a list of the unique Linux systems affected. Note that everything that is not Linux has been filtered out. That is why I was getting increasingly alarmed during the last few weeks."

bshipp

2 年前議論

This is the worry. It seems like a really unnecessary privilege escalation.

bshipp

2 年前議論

I guess the important question is whether or not these things are blocked by default or require user intervention to disable cups? Sure, many of us block all ports by default and either route everything behind a reverse proxy or punch very specific holes in the firewall that we know are there and can monitor, but someone firing up an ubuntu distribution for their first foray into linux is probably not thinking that way.

bshipp

2 年前議論

I don't know if I would say it's a nothing burger, but i don't see how it affects important servers. It might impact a number of linux desktops and, if they are linked to important servers, provide a backdoor access into important services.

Being able to run arbitrary code in a root account with no authentication would seem to be a pretty important security breach, although I don't think it's quite the level of danger it was built up to be.

bshipp

2 年前議論

This is entertaining reading. Although I don't know how pervasive this issue is, from the chunk i have read so far I can see why he was concerned that it was relatively trivial to have a target system accept anything identifying itself as a printer and being able to inject malicious code into the machine.

I was going to make fun of him wasting his sabbatical on hacking a printer service but I gotta admit I'd have fallen down the same rabbit hole if I stumbled on it. It's a cool hack.

bshipp

2 年前議論

How does an attacker exploit this vulnerability?

  - An attacker can exploit this vulnerability if it can connect to the host via UDP port 631, which is by default bound to INADDR_ANY, in which case the attack can be entirely remote, or if it's on the same network of the target, by using mDNS advertisements.

What does an attacker gain by exploiting this vulnerability?

  - Remote execution of arbitrary commands when a print job is sent to the system printer.

How was the vulnerability discovered?

  - A lot of curiosity (when I noticed the \*:631 UDP bind I was like "wtf is this?!" and went down a rabbit hole ...) and good old source code auditing.

Is this vulnerability publicly known?

  - No, the bugs are not known and the FoomaticRIPCommandLine vulnerability is known to be already patched (it isn't).

Is there evidence that this vulnerability is being actively exploited?

  - Not to the best of my knowledge.

bshipp

2 年前議論

https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840e...

Original report

Affected Vendor:

  - OpenPrinting

Affected Product

  - Several components of the CUPS printing system: cups-browsed, libppd, libcupsfilters and cups-filters.

Affected Version

  - All versions <= 2.0.1 (latest release) and master.

Significant ICS/OT impact?

  - no

Reporter

  - Simone Margaritelli [[email protected]]

Vendor contacted?

  - yes The vendor has been notified trough Github Advisories and all bugs have been confirmed:

- https://github.com/OpenPrinting/cups-browsed/security/adviso...

- https://github.com/OpenPrinting/libcupsfilters/security/advi...

- https://github.com/OpenPrinting/libppd/security/advisories/G...

- https://github.com/OpenPrinting/cups-filters/security/adviso...

I'm also in contact with the Canonical security team about these issues.

Description

  - The vulnerability affects many GNU/Linux distributions:

[https://pkgs.org/download/cups-browsed]

Google ChromeOS:

https://chromium.googlesource.com/chromiumos/overlays/chromi...

Most BSDs:

https://man.freebsd.org/cgi/man.cgi?query=cups-browsed.conf&...

And possibly more.

<snip>

bshipp

2 年前議論

From an eating-popcorn perspective, I would find it truly entertaining that a printer package could somehow result in a 9.9 security vulnerability that is somehow worse than heartbleed. How many linux systems actually have cups installed and active?

bshipp

3 年前議論

Indeed, although because I heavily utilized Docker I also ended up using UFW-Docker. It was fairly straightforward to incorporate into my startup scripts.

https://github.com/chaifeng/ufw-docker

bshipp

3 年前議論

I was brand new to managing an Ubuntu Hetzner server and the moment I saw how many port 22 scans the server received i decided to try changing the port number, followed by key-only passwordless logins. My logs immediately shrank in size. I have never once had an issue having moved to non standard ports and, moreso, feel almost naked logging into port 22.

I know security through obscurity is not an answer, but judging by the reduction in port scanning i've seen after moving as many standard ports as possible to new addresses above 20000 I have to believe its a reasonable first step. How many script kiddies are scanning all 65500 ports for each IP address?

bshipp

3 年前議論

You're a legend, thanks for posting that.

bshipp

3 年前議論

Just opened the Play store and there are numerous Harmony apps. Could you provide a link, please?

bshipp

3 年前議論

Judging by the declaration of war against Ukraine by Russia, it appears an underappreciated aspect of the equation is equal measures of senility and insanity.

bshipp

3 年前議論

This kind of reminds me of when the Concorde first started flying and technically could cancel IFR flight and proceed under visual flight rules over the atlantic because it was above 60,000 feet. An interesting legal possibility but likely not a practical consideration until driverless cars are afforded the same legal status as a human driver. As it currently stands, an AI would be considered a driving aid under the command of a licensed human driver, no different than cruise control.

bshipp

3 年前議論

In many ways its no different than electronic musicians building songs based on short samples of older songs. I have no doubt there will be rulings supporting the sort of creativity you're discussing at some point in the not so distant future.

bshipp

3 年前議論

Some people obviously prefer the old days when security problems were hidden within proprietary code so the only people who knew about them were the ones who found the exploit.

bshipp

3 年前議論

If water was priced appropriately it would incentivize hydroponics that captures and recirculates waste water to minimize usage.

bshipp

3 年前議論

As a simple example, Threading in Python works good for i/o-bound operations like scraping a website, whereas Multiprocessing works best for CPU-bound operations like result hashing/transforming the data you just scraped.

bshipp

3 年前議論

I understand everyone wants concurrency because that's the way everything else in programming works these days, but SQlite in memory or on an SSD (in WAL mode) writes so fast that it makes infinitely more sense to dedicate a single database "write" worker that deals with the dB itself while allowing multiple "read" workers to access the database concurrently. Other workers are spawned to process their data and shovel their writes into a queue to feed that single worker.

In my experience, the CPU utilization of process workers preparing data into SQL statements is generally the chokepoint in most/script programs instead of SQlite write speeds themselves. Of course, this is dependent on numerous factors such as the existence of indices, compexity of write operation, etc., but--as a rule--SQlite is much more efficient if I dedicate one process to handle all writes and optimize that process for speed (i.e. batch writes, etc.).

コメント