Angriffe auf UNIX-Systeme über CUPS

 (evilsocket.net)
1 Punkte von GN⁺ 2024-09-27 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn der automatische Drucker-Erkennungspfad von CUPS mit fehlender Validierung von IPP-Attributen zusammenkommt, kann ein entfernter, nicht authentifizierter Angreifer bösartige Druckerkonfigurationen einschleusen und beim Drucken sogar die Ausführung beliebiger Befehle auslösen
  • Ausgangspunkt des Angriffs ist das Verhalten von cups-browsed, auf UDP-Port 631 Pakete aus beliebigen Quellen anzunehmen und daraufhin eine Get-Printer-Attributes-IPP-Anfrage an eine vom Angreifer kontrollierte URL zu senden
  • Die Schwachstellen teilen sich in CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 und CVE-2024-47177 auf und reichen von der PPD-Erzeugung in libcupsfilters, libppd und cups-filters bis zum Ausführungspfad von foomatic-rip
  • Betroffen sind die meisten GNU/Linux-Distributionen, einige BSD-Systeme, möglicherweise auch Oracle Solaris sowie Chromium/ChromeOS; bei öffentlichen IPv4-Scans wurden Callbacks von Hunderttausenden Geräten und bis zu 200.000 bis 300.000 gleichzeitige Clients beobachtet
  • Praktisch sollten nicht benötigte cups-browsed-Instanzen deaktiviert oder entfernt und CUPS-Pakete aktualisiert werden; falls Updates schwierig sind, sollte das Blockieren von UDP 631 und bei Bedarf auch von DNS-SD-Traffic geprüft werden

Kernelemente der Schwachstellenkette

  • Diese Kette beginnt bei der automatischen Drucker-Erkennung von CUPS und führt über die Verarbeitung von IPP-Attributen und die Erzeugung von PPD-Dateien bis zur Ausführung von Filtern
  • Die zentralen Schwachstellen greifen in vier Stufen ineinander
    • CVE-2024-47176: cups-browsed bis einschließlich 2.0.1 bindet an UDP INADDR_ANY:631 und vertraut Paketen aus beliebigen Quellen, wodurch Get-Printer-Attributes-IPP-Anfragen an vom Angreifer kontrollierte URLs ausgelöst werden
    • CVE-2024-47076: cfGetPrinterAttributes5 in libcupsfilters bis einschließlich 2.1b1 validiert oder bereinigt vom IPP-Server empfangene Attribute nicht und gibt sie an das CUPS-System weiter
    • CVE-2024-47175: ppdCreatePPDFromIPP2 in libppd bis einschließlich 2.1b1 schreibt IPP-Attribute ohne Validierung oder Bereinigung in temporäre PPD-Dateien und erlaubt so das Einfügen angreiferkontrollierter Daten
    • CVE-2024-47177: foomatic-rip in cups-filters bis einschließlich 2.0.1 erlaubt über den PPD-Parameter FoomaticRIPCommandLine die Ausführung beliebiger Befehle

Angriffseinstieg und Auswirkungsbereich

  • Ein entfernter, nicht authentifizierter Angreifer kann die IPP-URL eines bestehenden Druckers unauffällig auf eine bösartige URL umstellen oder die Installation eines neuen Druckers bewirken
  • Die eigentliche Befehlsausführung findet auf dem betroffenen Computer beim Start eines Druckauftrags statt
  • Es gibt zwei Einstiegspunkte
    • WAN / öffentliches Internet: Ein entfernter Angreifer sendet Pakete an UDP 631; eine Authentifizierung ist nicht erforderlich
    • LAN: Ein lokaler Angreifer kann zeroconf-, mDNS- oder DNS-SD-Ankündigungen fälschen und über denselben Codepfad RCE erreichen
  • CUPS und cups-browsed sind auf mehreren UNIX-artigen Systemen paketiert
  • Bei mehrwöchigen Scans des gesamten öffentlichen IPv4-Adressraums mehrmals täglich meldeten sich nach dem Senden von UDP-Paketen Hunderttausende Geräte zurück; beobachtet wurden Spitzen von 200.000 bis 300.000 gleichzeitigen Clients

Der von cups-browsed offengehaltene Pfad

  • Auf einem Ubuntu-Laptop wurde bei netstat -anu ein lauschender UDP-Port auf 0.0.0.0:631 entdeckt
  • Eine Prüfung mit lsof -i :631 zeigte, dass TCP 631 von cupsd und UDP 631 von cups-browsed verwendet wurde
  • In ps aux war zu sehen, dass der Prozess cups-browsed als root lief
  • cups-browsed ist Teil des CUPS-Systems und dient dazu, neue Drucker zu erkennen und automatisch zum System hinzuzufügen
  • Ein Blick in den Quellcode zeigte, dass der Dienst an INADDR_ANY:631 UDP gebunden war und UDP-Pakete im Format HEX_NUMBER HEX_NUMBER TEXT_DATA erwartete
  • Wenn die Standardkonfigurationsdatei weitgehend auskommentiert ist, werden Zugriffsbeschränkungen praktisch schwach

Parsing-Probleme und weitere Bugs

  • Das CUPS-Paket selbst ist in oss-fuzz enthalten, für cups-browsed scheint es jedoch keine Fuzzing-Abdeckung zu geben
  • Nachdem ein AFL-basiertes Fuzzing-Ziel rund um process_browse_data gebaut wurde, lösten fünf Eingaben einen stack-buffer-overflow aus
  • Als Ursache wurde ein Ablauf genannt, bei dem in zwei Schleifen Zeiger dereferenziert werden, bevor die Abbruchbedingung geprüft wird
  • Danach wurden an Stellen der Sperrbehandlung außerdem eine race condition und eine mögliche DoS-Schwachstelle entdeckt
  • Diese Probleme wurden Entwicklern und CERT gemeldet, waren nach Angaben des Forschers jedoch weder anerkannt noch gepatcht

IPP-Anfragen und PPD-Injektion

  • found_cups_printer behandelt eines der aus dem UDP-Paket geparsten Textfelder als URL
  • Diese URL und zugehörige Daten laufen über examine_discovered_printer_record und create_remote_printer_entry weiter bis zu einem Aufruf von cfGetPrinterAttributes aus libcupsfilters
  • Sendet ein Angreifer ein Paket im Format 0 3 http://<ATTACKER-IP>:<PORT>/printers/whatever, verbindet sich das Ziel-cups-browsed mit der vom Angreifer kontrollierten URL
  • Beim Verbindungsaufbau enthielt der User-Agent-Header Kernel-Version und Architektur; in einigen Anfragen wurde auch der Benutzername des Zielsystems gemeldet
  • Das Internet Printing Protocol ist ein Kommunikationsprotokoll zwischen Clients und Druckern oder Druckservern und wird etwa für Statusabfragen und das Einreichen von Druckaufträgen verwendet
  • Das Zielsystem erkennt den Angreifer-Server als Drucker und sendet eine in HTTP gekapselte Get-Printer-Attributes-Anfrage
  • Wurde mit dem ippserver python package auf kontrollierbare Attribute geantwortet, wurde der gefälschte Drucker ohne Benutzerbenachrichtigung als lokaler Drucker hinzugefügt

Ausführungspfad über PPD und foomatic-rip

  • In Debug-Logs waren die Erstellung der Druckerwarteschlange, die Erzeugung einer temporären PPD-Datei sowie deren Nutzung und Bearbeitung zu sehen
  • Die Funktion create_queue übergibt IPP-Attribute an die API ppdCreatePPDFromIPP2 aus libppd
  • ppdCreatePPDFromIPP2 schreibt vom Angreifer kontrollierte Textattribute wie printer-make-and-model ohne Validierung oder Escaping in die PPD-Datei
  • Eine Datei vom Typ PostScript Printer Description ist eine Textdatei, die Druckerfunktionen und -fähigkeiten beschreibt und in CUPS festlegt, welche Funktionen ein Drucker hat und wie er verwendet wird
  • Unter mehreren Direktiven innerhalb von PPD ist cupsFilter2 eine CUPS-Erweiterung, die bei Druckaufträgen ausführbare Dateien unter /usr/lib/cups/filter als Filter starten kann
  • foomatic-rip wird als Filter behandelt, der über die Direktive FoomaticRIPCommandLine in der PPD Befehle ausführen kann
  • In der Vergangenheit gab es in foomatic-filters Korrekturen zu CVE-2011-2964 und CVE-2011-2697, doch diese Änderungen wurden laut Analyse bei der Integration in CUPS nicht portiert
  • Auch in der neueren CVE-2024-35235 wird eine Ausführung beliebiger Befehle über FoomaticRIPCommandLine erwähnt
  • Nach Darstellung der CUPS-Entwickler ist es sehr schwierig, ohne Bruch bestehender Treiber einzuschränken, was an FoomaticRIPCommandLine übergeben werden kann; möglicherweise sind Hunderte älterer Druckermodelle aus der Zeit vor 2010 ausschließlich auf Foomatic angewiesen

Ablauf zur Reproduktion von RCE

  • Die RCE-Kette besteht aus drei Schritten
    • Das Zielsystem wird dazu gebracht, sich mit dem bösartigen IPP-Server des Angreifers zu verbinden
    • Es werden angreiferkontrollierte IPP-Attribut-Strings zurückgegeben, um Direktiven in eine temporäre PPD-Datei einzuschleusen
    • Wird ein Druckauftrag an den gefälschten Drucker gesendet, werden die PPD-Direktiven und Befehle ausgeführt
  • In der IPP-Server-Konfiguration wurde die Befehlsausführung dadurch aufgebaut, dass ein PPD-String geschlossen, eine neue Zeile eingefügt und anschließend die Direktiven FoomaticRIPCommandLine und cupsFilter2 eingefügt wurden
  • Das Demo-Ziel war ein vollständig gepatchtes Ubuntu 24.04.1 LTS mit cups-browsed 2.0.1; auf der Angreifer-Maschine wurde die Befehlsausführung erreicht
  • Dieser Ablauf funktioniert nur, wenn mehrere Verarbeitungsschritte in cups-browsed, libcupsfilters, libppd und cups-filters zusammenwirken

Gegenmaßnahmen und Empfehlungen

  • Wenn cups-browsed nicht benötigt wird, wird empfohlen, den Dienst zu deaktivieren und zu entfernen
  • Die CUPS-Pakete des Systems sollten aktualisiert werden
  • Wenn keine Updates möglich sind und der Dienst benötigt wird, sollte UDP 631 blockiert werden
  • Je nach Umgebung kann auch DNS-SD-Traffic blockiert werden, was sich in zeroconf-Umgebungen jedoch schwer umsetzen lässt
  • Der Forscher erklärte als persönliche Empfehlung, CUPS-Dienste, Binärdateien und Bibliotheken von seinen Systemen zu entfernen und nicht auf UNIX-Systeme zu drucken
  • Er fügte hinzu, auch zeroconf-, Avahi- und Bonjour-Listener zu entfernen

Offenlegung und Nacharbeiten

  • Die eigentliche Forschung dauerte nur wenige Tage, doch von der Einreichung eines Security Advisorys am 5. September im OpenPrinting-cups-browsed-Repository bis zur Veröffentlichung vergingen 22 Tage
  • Die zugehörigen Diskussionen führten zu Security Advisorys für cups-browsed, libcupsfilters, libppd und cups-filters
  • Die Forschung nahm zwei Tage in Anspruch, der funktionierende Exploit 249 Zeilen, und im Offenlegungsprozess fielen Diskussionen, E-Mails, Nachrichten und mehr als 100 Seiten Text an
  • Zur Kontroverse um den CVSS-Wert 9.9 hieß es, der anfängliche Wert 9.9 stamme aus einem VINCE-Bericht, sei von einem RedHat-Ingenieur geschätzt und von einem weiteren Ingenieur geprüft worden
  • Der Forscher meint, die anfänglichen 9.9 seien wohl wegen der leichten Ausnutzbarkeit von RCE und der weiten Verbreitung der Pakete vergeben worden, ergänzt aber, dass er die Auswirkungen selbst nicht mit 9.9 einstufen würde
  • Er erklärte außerdem, dass der exakte Markdown-Bericht und der Exploit, die nur mit CERT VINCE geteilt worden waren, durchgesickert seien
  • Das anfängliche exploit.py versandte nur UDP-Pakete und startete einen bösartigen IPP-Server, wurde später aber um zeroconf-Ankündigungen ergänzt und damit stärker toolisiert
  • Anschließend wurde es in Go neu geschrieben und in bettercap integriert, ergänzt um die Fähigkeit, im LAN über zeroconf, Bonjour und Avahi angekündigte Dienste transparent nachzuahmen sowie um IPP-bezogene Verarbeitung
  • Im nächsten Artikel soll es um Angriffe auf Apple macOS mit einem noch nicht veröffentlichten bettercap-Modul gehen; der Zeitplan ist wegen anderer Offenlegungsverfahren noch unklar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-27
Meinungen auf Hacker News

  • Ich dachte erst, das sei ein Witz. Es geht darum, dass „ein entfernter, nicht authentifizierter Angreifer die IPP-URL eines vorhandenen Druckers durch eine bösartige URL ersetzen oder einen neuen installieren kann, sodass beim Starten eines Druckauftrags auf diesem Computer beliebige Befehle ausgeführt werden können“. Heartbleed lag bei 7.5, und das hier wirkt nicht so, als könne es 9.9 sein.
    Der ursprüngliche Tweet sprach von „nicht authentifizierter Remote Code Execution auf allen GNU/Linux-Systemen usw.“, tatsächlich ist CUPS in vielen Distributionen aber entweder nur an Loopback gebunden oder gar nicht installiert.
    Außerdem heißt es, man habe über mehrere Wochen hinweg den gesamten öffentlichen IPv4-Adressraum mehrmals täglich gescannt und Callbacks von Hunderttausenden Geräten erhalten. Wenn ich das richtig verstehe, bedeutet das, dass es im gesamten öffentlichen IPv4-Raum etwa 300.000 offene CUPS-Instanzen gab; damit Remote Code Execution passiert, müsste der jeweilige CUPS-Server dann auch einen Druckauftrag erhalten, was bei den meisten wohl nicht der Fall sein dürfte.

    • Wenn man den Artikel liest, ist das durchaus ziemlich übel, aber eher in dem Sinne, dass der cups-browsed-Daemon selbst verschwinden sollte und das Linux-Ökosystem ernsthaft über die Zukunft von CUPS diskutieren muss.
      Die Bugs wirken erstaunlich simpel, und am Ende ist es ein ziemlich ernstes Sicherheitsproblem, aber nicht das Niveau an Upstream-Reaktion, das man bei einem standardmäßig installierten Desktop-Linux-Paket erwarten würde.
      Trotzdem ist es ganz sicher keine weltbewegende CVSS-9.9-Panik.
    • Fairerweise hat der Autor auch gesagt: „Nach Impact würde ich es nicht als 9.9 einstufen, aber was weiß ich schon.“
    • Es gibt auch einen Buffer Overflow, der ohne Benutzeraktion ausnutzbar ist. Der foomatic-Pfad, der einen Druckauftrag erfordert, war nur einer der am einfachsten zu scannenden und auszunutzenden Wege.
    • Über das Meme „Look at me, I'm the printer now“ musste ich laut lachen. Unabhängig von der Schwerebewertung war zumindest der Witz ein echter Treffer.
    • Heartbleed ist ein Speicherleck, das hier ist vollständige Remote Code Execution ohne Benutzeraktion. Remote Code Execution bedeutet natürlich vollständigen Informationsabfluss und noch mehr.
      Genauer gesagt wird die Ausführung verzögert: Sie passiert, wenn der Benutzer das nächste Mal mit den vom Angreifer geänderten Druckereinstellungen auf seinem Drucker druckt; die Schwachstelle liegt nicht in cupsd, sondern in cupsd-browser.
      Mit der Haltung des Autors kann es Probleme geben, aber diese Schwachstelle selbst ist wirklich eine große Sache.

  • Wer CUPS ins Internet exponiert, ist auf einem Niveau der Sorglosigkeit, das kein CVE mehr erreichen kann.

    • Der verwundbare Dienst scheint auf 0.0.0.0 zu lauschen, und das ist besorgniserregend. Das bedeutet, dass man standardmäßig im LAN angreifbar ist und, wenn der Server im Internet exponiert ist, Port 631 explizit blockieren muss.
      Natürlich muss der Benutzer zum Triggern etwas drucken, und persönlich glaube ich nicht, dass ich unter Linux je etwas gedruckt habe, aber die Behauptung, Callbacks von Hunderttausenden Linux-Maschinen erhalten zu haben, klingt plausibel.
    • In diesem Fall klingt „CUPS ins Internet exponieren“ eher wie „einen mit dem Internet verbundenen Linux-Desktop betreiben“. Ich würde das nicht machen, aber völlig verrückt ist es auch nicht; man würde erwarten, dass eine standardmäßige Debian-Desktop-Installation auch ohne Firewall ausreichend sicher ist.
      Zumindest sollte ein Linux-Laptop in einem Flughafen-WLAN nicht gegenüber allen anderen Geräten stark verwundbar werden.
    • Wer in ein Café geht und öffentliches WLAN nutzt, exponiert CUPS gewissermaßen und kann ausgenutzt werden. Ein einfaches Abtun hilft niemandem.
    • Absurderweise läuft CUPS nicht als stark sandboxed Benutzerprogramm, sondern als System-Daemon.
    • Dennoch ist es ein kompletter Sieg für laterale Bewegung und Rechteausweitung.

  • Je nachdem, wie man den Scope-Indikator von CVSSv3 interpretiert, scheint es genauer 8.8 oder 9.6 zu sein.
    Kurz gesagt: Bei einigen Desktop-Linux-Varianten ist CUPS im LAN auf 0.0.0.0 erreichbar, läuft als root und ist für nicht authentifizierte Remote Code Execution anfällig. Auf den meisten serverorientierten Linux-Distributionen wie Ubuntu Server oder CentOS ist es kein Standarddienst, aber bei den meisten Desktop-Linux-Varianten scheint es standardmäßig gestartet zu werden.
    Um die Remote Code Execution auszulösen, muss der Benutzer der verwundbaren Linux-Maschine nach der Ausnutzung ein Dokument drucken.
    evilsocket sagte, er habe Hunderttausende Callbacks erhalten, und selbst wenn die meisten von uns unter Linux kaum drucken, könnte eine Auswirkung dieser Größenordnung ausreichen, um ein großes Botnet aufzubauen.

    • An Universitäten gibt es viele Leute mit Linux-Desktops mit öffentlichen IP-Adressen, die ständig drucken, ob Paper, eigene Texte oder Texte anderer.
    • Der Marktanteil von Linux-Desktops liegt selbst ohne ChromeOS bei ungefähr 4,5 %. Auch wenn die meisten von uns nicht drucken, dürfte es immer noch ziemlich viele Druckaufträge von Linux-Hosts geben.
    • Heartbleed lag bei 7.5 und nur 0.4 unter dem xz-Vorfall; ich verstehe nicht, wie das hier 9.6 sein kann.

  • Ich hatte cupsd im Internet offen und geriet bei der Nachricht etwas in Panik, aber wie schon der Titel hier ist auch dieses Thema teilweise falsch dargestellt. Das Problem liegt nicht im zentralen cupsd, sondern in cups-browsed, einem separaten Paket bzw. einer separaten Komponente.
    Gentoo Linux, das ich für Server nutze, stellt cups-browsed als separates Paket bereit, und da ich es nicht installiert habe, bin ich nicht betroffen. Auch die meisten CUPS-Nutzer, die dieses Zusatzpaket nicht installiert haben, sind von diesem Bug nicht betroffen.
    Zu sagen, alle Systeme mit CUPS könnten gehackt werden, stellt den Umfang falsch dar.

    • Debian ist zwar eher konservativ, aber mir gefiel schon immer nicht, dass bei der Installation von cups normalerweise cups-browsed standardmäßig mitkommt. Mit „no install recommends“ scheint sich das lösen zu lassen, aber meiner Erinnerung nach ziehen zusätzliche Treiber wie hplip es auch wieder herein.
      Zu Hause habe ich den Dienst einfach deaktiviert, aber es ist ziemlich nervig, dass immer mehr Software ausufert und Komponenten, die optional sein sollten, praktisch verpflichtend macht.
      Ein ähnliches Beispiel ist avahi-daemon. Wenn man versucht, ihn auf Desktop-Debian/Ubuntu zu entfernen, wird wahrscheinlich auch andere Software mit entfernt, bei der man sich fragt, warum avahi eine harte Abhängigkeit sein muss.

  • Der Punkt, dass „von Forschern zu viel erwartet und als selbstverständlich angesehen wird, weil Triager so auftreten, als müssten Sicherheitsforscher wie du erst beweisen, dass sie es wert sind, gehört zu werden“, ist nachvollziehbar, aber es gibt leider auch eine unschöne Realität.
    Auf jeden gut recherchierten Bericht dieser Art kommen 57 minderwertige Spam-Reports, mit denen jemand eine Bug-Bounty-Prämie herausschlagen oder eine CVE-Entdeckung in den Lebenslauf schreiben will. Gerade seit LLMs verbreiteter sind, lässt sich solcher Spam leicht überzeugend wirken lassen.
    Eine traurige Situation, aber man kann Entwicklern ihre Skepsis nicht vollständig vorwerfen.

  • Kurz gesagt: cups-browsed lauscht auf UDP-Port 631 und kann ohne Bestätigung durch den Nutzer automatisch Drucker installieren.
    Ein Angreifer nutzt dieses „Feature“, um ohne Nutzerbestätigung einen gefälschten Drucker zu installieren, der mit einem von einem beliebigen Host herunterladbaren Custom-Treiber versehen ist, und legt einen Befehl fest, der ausgeführt werden soll, wenn ein Druckauftrag gesendet wird.
    Wenn der Nutzer etwas auf diesem gefälschten Drucker druckt, wird dieser Befehl ausgeführt.

    • Da CUPS 1999 eingeführt wurde, mag eine automatische Installation ohne Nutzerbestätigung damals sinnvoll gewesen sein. Warum das heute noch vorhanden ist, verstehe ich allerdings nicht.

  • In diesem Fall scheinen die Distributionen cups-browsed als Feature mitzuliefern, aber ich fand es schon immer schlecht, dass Ubuntu/Debian und vermutlich alle deb-basierten Distributionen bei der Installation fast alle Dienste automatisch starten.
    Das bedeutet, dass man nur ein Paket installiert und dadurch versehentlich ein anderer Netzwerkdienst, der als Abhängigkeit installiert wurde, offen sein kann.
    exim4 ist ein bekanntes Beispiel, wobei fairerweise die Voreinstellung nur auf localhost lauscht, also vielleicht kein großes Problem ist. Ich habe gerade cups-browsed auf einer Debian-Maschine installiert, und es wurden zwei Dienste gestartet, die auf 0.0.0.0 lauschen (cups-browsed und avahi).
    Bei Arch/Gentoo und Distributionen aus der CentOS-Familie ist das nicht so.

  • Der ursprüngliche CVSS-Score auf Twitter gab an, dass keine Nutzerinteraktion erforderlich sei. Wenn man aber die Remote-Code-Execution-Kette auf der Seite liest, heißt es dort: „Warten, bis ein Druckauftrag an den gefälschten Drucker gesendet wird, damit die PPD-Direktive und der daraus resultierende Befehl ausgeführt werden.“
    Wenn Alice nicht auf Drucken klickt, scheint kein Druckauftrag ausgelöst zu werden; ich frage mich also, was ich übersehe. Es geht mir weniger darum, evilsocket zu misstrauen, als darum, mein Verständnis zu prüfen.

    • Es gibt auch einen per Fuzzer gefundenen Buffer Overflow, der ohne Nutzerinteraktion zu Remote Code Execution führen könnte. Allerdings hatte der Autor nicht genug Expertise in diesem Bereich, um einen tatsächlichen Exploit zu bauen.
    • Das hängt von der Definition von „Interaktion“ ab. Soweit ich es verstehe, muss Alice kein vom Angreifer bereitgestelltes Dokument drucken; es reicht, wenn sie einfach irgendetwas druckt.

  • Jedes Mal, wenn ich unter MacOS etwas drucken muss, fällt mir wieder ein, wie sehr ich Drucker und druckerbezogene Software hasse. Ich arbeite seit 40 Jahren mit Computern, und wirklich in jedem Jahrzehnt sind Drucker noch lästiger geworden.

    • Es ist interessant, dass die FSF-Bewegung zu einem erheblichen Teil dadurch angestoßen wurde, dass Stallman sich über die Qualität von Druckertreibern ärgerte. Trotzdem hat diese Bewegung aus irgendeinem Grund in 40 Jahren die Qualität druckerbezogener Software nicht sichtbar verbessert.
    • Ich habe über 10 Jahre lang Drucker-Code geschrieben. Ich verstehe, wie schwierig die technischen Probleme sind, aber die Anbieter machen die Lage noch viel schlimmer. Drucker sind abscheulich, und ich denke, der LaserJet III war der Höhepunkt.
    • Ich finde, Drucker sind viel besser als vor 10 Jahren. Zumindest unter MacOS und iOS habe ich keine Probleme, Drucker zu finden und zu drucken. Vor 10 Jahren war es mühsam, heute läuft es nach meinem Maßstab reibungslos, und eine Treiberinstallation ist auch nicht nötig.
    • Neueste Meldung: HP fügt seinen Druckertreibern KI hinzu. Kein Witz: https://hardware.slashdot.org/story/24/09/27/0030239/hp-is-a...
    • Man verliert zwar die Jobsteuerung, aber wenn man das Dokument in PostScript umwandelt und es dann per netcat an den Druckerport schickt, funktioniert es gut.
      pdf2ps - | nc 9001