16 jaar oude kwetsbaarheid ontdekt in laserprintersoftware HP, Samsung en Xerox

Er is een 16 jaar oude kwetsbaarheid gevonden in de drivers van HP-, Samsung- en Xerox-laserprinters. Via de kwetsbaarheid zouden aanvallers adminrechten op de systemen van slachtoffers kunnen verkrijgen. Er zijn inmiddels patches uitgebracht, die het probleem verhelpen.

Cybersecuritybedrijf SentinelOne, dat het lek opmerkte, schrijft dat in totaal 'miljoenen verkochte printers' kwetsbaar zouden zijn. Het betreffen allemaal laserprinters. Het gaat om zeker 380 verschillende modellen van HP en Samsung, naast twaalf verschillende laserprinters van Xerox. Er zijn volgens SentinelOne geen aanwijzingen dat de kwetsbaarheid momenteel actief wordt misbruikt.

HP heeft inmiddels patches uitgebracht, die de kwetsbaarheid moeten oplossen. Die patch werkt op getroffen printers van HP en Samsung. Xerox heeft ook software-updates uitgebracht die het probleem moeten verhelpen. Gebruikers wordt aangeraden om de update zo snel mogelijk te installeren. De patches moeten ook beschikbaar komen via Windows Update.

De kwetsbaarheid staat bekend als CVE-2021-3438 en krijgt een hoge ernstigheidsscore van 7,8. Via de bug zouden hackers de kwetsbaarheid kunnen uitbuiten door een buffer overflow te veroorzaken in de ssport.sys-driver, waarmee hackers adminrechten kunnen verkrijgen. De kwetsbare driver wordt automatisch meegeïnstalleerd met de printersoftware van HP, Xerox en Samsung, en wordt automatisch geladen bij het opstarten, meldt SentinelOne. De kwetsbaarheid kan ook worden uitgebuit wanneer de printer niet is aangesloten.

Om dat te bereiken, moeten hackers echter eerst digitaal toegang krijgen tot het systeem van een slachtoffer. Hackers moeten dus eerst op een andere manier de computer van een slachtoffer binnendringen. Als de hackers dit bereiken, kunnen ze de beveiligingsfout relatief eenvoudig uitbuiten, zonder dat daarvoor extra interactie van het slachtoffer nodig is. Hackers kunnen daarna code in kernelmodus uitvoeren, waardoor ze bijvoorbeeld programma's kunnen installeren en bestanden kunnen bekijken, wijzigen of versleutelen.

Dit is de vierde aan printers gerelateerde kwetsbaarheid die in korte tijd aan het licht komt. Eind juni werd er bijvoorbeeld melding gemaakt van een zeroday in de Print Spooler Service van Windows, die overigens niet gerelateerd is aan de hierboven genoemde driverkwetsbaarheden van HP, Samsung en Xerox. Het eerste Print Spooler-probleem is inmiddels gepatcht, maar vorige week waarschuwde Microsoft voor nog een beveiligingsprobleem in de Print Spooler-dienst.

De kwetsbare driver, die automatisch wordt opgestart (links) en de patch via HP. Afbeeldingen via SentinelOne

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (70)

Komt het er op neer dat die drivers zelf al met admin rechten draaien en dat je door de hack op deze manier ook admin rechten kan verkrijgen voor willekeurige code? Zo ja waarom hebben die drivers dan admin rechten?

[Reactie gewijzigd door juanita op 22 juli 2021 10:24]

De CVE spreekt over een 'mogelijke buffer overflow'. Wanneer leren we nou eens dat we geen tools meer moeten gebruiken dat dit überhaupt toe laat? Het is een opgelost probleem en toch gebeurt het nog zo veel.

Buffer overflow is niet echt een opgelost probleem.
Buffer overflow is gewoon een fout in code, die kan iedereen maken. Niet echt iets wat ooit "opgelost" gaat zijn.

Je kunt het voorkomen door programmeertalen te gebruiken die geen buffer overflows toestaan. Bijvoorbeeld Rust, maar vrijwel alle drivers worden nog steeds geschreven in C/C++.

Edit: voor de duidelijkheid, mijn reactie gaat over of het mogelijk is om buffer overruns in nieuwe software te voorkomen. Niet over die 16 jaar oude software.

[Reactie gewijzigd door Ablaze op 21 juli 2021 23:01]

Bug: 16 jaar oud
Rust: 11 jaar oud

Die bug is ouder dan menig Tweaker die hier een ' mening' over heeft...

Nee.
Ook in Rust kun je nog steeds een buffer-overflow maken.
In puur Rust is het zo goed als onmogelijk, maar vrijwel iedere niet-triviale Rust code moet ergens een keer een system-call of een externe API aanroepen.
En dat gaat vrijwel altijd weer via een ouderwetse C-call en C pointers.
En dan loop je weer tegen hetzelfde probleem aan.

Het gaat er ook niet om dat het volledig onmogelijk is, maar in C is het vrijwel onvermijdelijk dat er een op de zoveel keer een foutje gemaakt wordt en dit soort bugs dus overal zitten.
Als je de standaard API van Rust gebruikt is dit probleem vrijwel opgelost.

Als je de standaard API van Rust gebruikt is dit probleem vrijwel opgelost.

Als het probleem een vereiste kent om opgelost te zijn, dan bestaat er dus een tweede probleem voor het geval het vereiste niet aanwezig is / gehaald wordt. Oftewel er blijft een onopgelost probleem aanwezig.

Het gebruiken van de standaard API is de meest logische manier en hiermee is het onmogelijk om dezelfde fouten te maken als met de C standaard API's (de hele reden dat Rust bestaat zo ongeveer)
Natuurlijk kan een 'echte programmeur' met de nodige inspanning domme dingen doen (net als 'echte chauffeurs' hun auto ook met lane assist de vangrail in kunnen werken), maar als je 99% van de probleemgevallen kan oplossen door je werkwijze aan te passen kan je daarna extra focussen op de plekken (die dan duidelijk te vinden zijn) waar nog potentiële onveiligheid in zit.
Ik geloof niet dat we ooit 100% veiligheid gaan bereiken, maar accepteren dat het niet beter kan terwijl het in veel gevallen om vermijdbaar risico gaat vind ik niet acceptabel.

Nog even los van de vraag welke rust developer dit zou gaan doen:
"The Rust project's developer survey from the first quarter of 2020 attracted less than 4,000 developers"

Talen die het ontstaan van buffer overflows drastisch verminderen bestaan al veel langer. Een goed voorbeeld is Ada.

"gebruik gewoon taal X dan heb je dit probleem niet" is niet een echte oplossing.

Als je aan iemand met een houten huis aangeeft dat zijn brandbaarheids probleem is opgelost door stenen huizen is kan de man niet zo een twee drie zijn huis vervangen, laat staan dat het echt vergelijkbaar is.

Nee, maar als die huizen continu afbranden zou je misschien eens na kunnen denken of er preventief maatregelen genomen kunnen worden, ook al betreft het maar een deel van de bouw.

Maar het huis is dus al gebouwd (=de software bestaat al).

Dit is letterlijk zeggen: waarom maken we niet gewoon bug-vrije software?

goed plan....

Helemaal niet, maar in plaats van een enorm pakket te herbouwen zou je prima kunnen kijken of er delen zijn die 'gerenoveerd' moeten worden.
Je kan altijd een extra afschermingslaag toevoegen, 'defense in depth' principe.

Wanneer een huis wat gebouwd is begint te verzakken ga je stutten in plaats van wachten tot het hele spul in elkaar zakt...

Als het huis verzakt is de bug dus gevonden... wie gaat er nu stutten als het huis gewoon nog staat?

Een huis is toch even net iets minder vervangbaar dan een stukje software. Bedrijven zouden kunnen overwegen om (delen van) hun software (in stappen) om te bouwen naar modernere/veiligere programmeertalen. Dat hoeft niet altijd nodig te zijn maar bij cruciale onderdelen van een systeem waarbij de risico's aanzienlijk zijn zou het zeker te overwegen zijn.

Maar het eeuwenoude debacle: dat kost geld. En het gezegde "don't fix it if it ain't broken" zal ook van toepassing zijn, totdat ze erachter komen dat het wél broken is... Telkens weer... Software wordt nog steeds door mensen geschreven en mensen maken fouten dus het zou fijn zijn als er zoveel mogelijk tooling wordt gebruikt die dergelijke fouten voorkomt of er tussenuit vist.

Apple Silicon heeft W^X memory pages waardoor geheugendelen niet als schrijfbaar en uitvoerbaar tegelijkertijd gemarkeerd kunnen worden.

Dit is geen oplossing, maar wel een extra laagje beveiliging.

De NX bit is al een tijdje ouder, en is ook al 16 jaar lang beschikbaar in Windows. W^X van OpenBSD is net een paar jaartjes ouder. Elk OS van de afgelopen 15 jaar heeft een vorm van Executable Space Protection.
Maar het is lang niet altijd bruikbaar, en dan nog steeds zou buffer overflows problematisch. Want je zou namelijk andere non-executable code kunnen overschrijven die vervolgens resulteert dat een andere code path genomen wordt omdat een variable opeens een andere waarde heeft.

e.g.
char[16] username;
bool is_authenticated;

iets te veel schrijven naar username, en is_authenticated is true.

Daar hebben we aslr voor!
https://en.m.wikipedia.or...pace_layout_randomization
Alleen... op Windows werkt dat enkel voor specifiek gelinkte binaries (maw de devver moet het enablen), en dat was nog niet zo in 2005 (pas vanaf vista/2008)

Nee dat fixed dat probleem niet. ASLR geeft random locaties voor het begin van executables, stacks, and heaps. Maar in de stack en heap zal data nog steeds geordend en mogelijk aligned zijn.
Wat ASLR oplost is het corrupten van memory in specifieke andere regios, omdat daarvan de locatie niet meer bekend is.

je kan niet alle software en code gaan reviewen en herschrijven. Vaak is er legacy-code die gebruikt wordt en/of nodig is voor oudere systemen en wordt die herbruikt totdat er een probleem bij opduikt zoals hier. Je gaat voorbij aan het feit dat deze bug maar liefst 16 jaar onder de radar is gebleven voordat er een exploit voor is opgedoken én ogenschijnlijk quasi onmiddellijk is opgelost door de maker.

Het is pas na 16 jaar publiek bekend. Dat is niet zomaar hetzelfde als het was 16 jaar geen probleem.

We kunnen dan natuurlijk gaan raden wat dan het risico was, maar daar gaat het niet om. Het doel is om risico zo veel mogelijk weg te nemen, niet in stand te houden of te door de tijd te laten verergeren.

Het probleem daarbij is dat het kennelijk nog normaal is om 16 jaar oude code te blijven gebruiken, terwijl dat niet zomaar redelijk is als kennis over veilig programmeren en zelfs wetgeving heel veel strenger zijn geworden. Maar zelfs dan vinden gebruikers als bedrijven het kennelijk wel normaal om computers na een aantal jaar af te schrijven (financieel voordelig) maar niet om software af te schrijven? Dat er nog ondersteuning is klinkt natuurlijk prettig, maar dat is niet zomaar genoeg doen om risico te beperken. Zeker niet als onduidelijk is waarom je 16 jaar oude drivers zou blijven accepteren die niet eens gemaakt zijn volgens beveiligingsprincipes die zelfs toen al gewoon waren in bijna alle grote besturingssystemen. Dan ben je risico's niet zo veel mogelijk aan het beperken maar ze eerder aan het verergeren.

Het is pas na 16 jaar publiek bekend. Dat is niet zomaar hetzelfde als het was 16 jaar geen probleem.

dat is exact wat ik schreef: onder de radar gebleven en nu is de exploit opgedoken.

We kunnen dan natuurlijk gaan raden wat dan het risico was, maar daar gaat het niet om. Het doel is om risico zo veel mogelijk weg te nemen, niet in stand te houden of te door de tijd te laten verergeren.

nee, het doel is om het product bruikbaar te maken en het risico zo veel mogelijk te beperken is een bijkomende vereiste geworden sinds een jaar of 10 (ja er werd uiteraard al langer naar gekeken, maar niet al secundaire vereiste).

Het probleem daarbij is dat het kennelijk nog normaal is om 16 jaar oude code te blijven gebruiken, terwijl dat niet zomaar redelijk is als kennis over veilig programmeren en zelfs wetgeving heel veel strenger zijn geworden. Maar zelfs dan vinden gebruikers als bedrijven het kennelijk wel normaal om computers na een aantal jaar af te schrijven (financieel voordelig) maar niet om software af te schrijven? Dat er nog ondersteuning is klinkt natuurlijk prettig, maar dat is niet zomaar genoeg doen om risico te beperken. Zeker niet als onduidelijk is waarom je 16 jaar oude drivers zou blijven accepteren die niet eens gemaakt zijn volgens beveiligingsprincipes die zelfs toen al gewoon waren in bijna alle grote besturingssystemen. Dan ben je risico's niet zo veel mogelijk aan het beperken maar ze eerder aan het verergeren.

bedrijven en gebruikers die zulke eisen stellen acht ik in staat om eerst research te doen of de juiste contracten af te sluiten met hun leveranciers en als ze dat niet doen de afweging hebben gemaakt tussen kost,keuze en risico.

Deze driver is trouwens geen 16 jaar oud, maar wordt nog actief onderhouden. Ze hebben de bug gewoon kunnen backtracen tot de driver die toen gebruikt was, niet toevallig rond de tijd van de introductie van windows vista (ironisch genoeg een OS waar voor het eerst sprake was van UAC).

[...]

dat is exact wat ik schreef: onder de radar gebleven en nu is de exploit opgedoken.

Ik gaf verduidelijking. Niet alles is kritiek als er een reactie komt.

nee, het doel is om het product bruikbaar te maken en het risico zo veel mogelijk te beperken is een bijkomende vereiste geworden sinds een jaar of 10 (ja er werd uiteraard al langer naar gekeken, maar niet al secundaire vereiste).

De wet stelt geen prioriteit aan bruikbaar maken van code, wel aan het zo veel mogelijk beperken van risico. Het is dus onredelijk om beperken een bijkomendheid te noemen en bruikbaarheid voorop te stellen omdat dat beter uit komt. Dat soort wetgeving bestaat al langer dan 10 jaar, via bijvoorbeeld de wetgeving op persoonsgegevens. Het bestaat ook al sinds zeker eind vorige eeuw als bekende toepassing, tenzij men opzettelijk weg wil kijken van veelvuldig toegepast worden van beveiligingsprincipes. Het is niet niks als unix systemen, het professionele windows os, apple en professionele hardware scheiding in rechten en accounts toepassen en door miljoenen bedrijven zo in gebruik was.

bedrijven en gebruikers die zulke eisen stellen acht ik in staat om eerst research te doen of de juiste contracten af te sluiten met hun leveranciers en als ze dat niet doen de afweging hebben gemaakt tussen kost,keuze en risico.

Het gaat er natuurlijk niet om wie daartoe in staat is maar dat ook daadwerkelijk doet en ook voldoende doet om echt risico te beperken. Ik denk niet dat het redelijk is om te veronderstellen dat veel bedrijven of personen die bijvoorbeeld persoonsgegevens verwerken echt weten dat deze driver hoge rechten kan geven, laat staan waarom het redelijk is dat het dat nodig heeft. Daarbij gaat het er natuurlijk om wie er niet toe in staat is en toch deze software gebruikt met alle risico's die ze hadden kunnen beperken.

Deze driver is trouwens geen 16 jaar oud, maar wordt nog actief onderhouden.

Ik lees niet dat het alleen om software gaat die vernieuwd is. Dat gebruikers als bedrijven de software blijven accepteren zonder dat duidelijk is waarom het te vertrouwen is verdwijnt daar als probleem niet mee.

Zeker niet als onduidelijk is waarom je 16 jaar oude drivers zou blijven accepteren die niet eens gemaakt zijn volgens beveiligingsprincipes die zelfs toen al gewoon waren in bijna alle grote besturingssystemen.

Hoe weet je dat, buffer overflows zijn al heel lang een probleem. Volgens mij enkel opgelost in applicatie talen, niet systeemtalen. Dit type probleem was al zeker 30 jaar bekend voor het hier in de code mis ging. Dan nog zijn menselijke fouten van alle tijden, zie ontplofte raket door input omrekenfactor cm vs inches.

Plus: wie heeft er nu software development capaciteit in overvloed, om alles dat er al is ook nog eens te herschrijven? Nogal krappe arbeidsmarkt op softwareontwikkeling.

Nieuwe code bevat tot slot ook vrolijk weer nieuwe fouten. Nu vallen ze je return adressen of heap aan in je managed code, beveiligingsgaten worden overal in gevonden.

Dat iemand meer rechten heeft dan nodig is. Software met fouten of een account zijn slechts middelen om een persoon ergens bij te laten kunnen waar dat niet hoort. Least privileges toepassen is al 20 jaar gebruik, het is al heel veel jaren een uitwerking van wetgeving voor bijvoorbeeld verwerken van persoonsgegevens. Dat je dat hoort toe te passen wil dus ook zeggen dat je geen software gaat of blijft gebruiken waarvan je niet eens weet waarom het echt die hoge rechten nodig heeft of kan bereiken. Anders pas je het principe nogal selectief toe, en dus de wet.

Dat nieuwe code nieuwe foute kan bevatten is geen excuus om dus code te gaan of blijven gebruiken zonder te weten waarom die te vertrouwen is of welke rechten het geeft. Het is dus belangrijk niet zomaar code te vertrouwen, en dus niet te accepteren dat leveranciers je niet kunnen of willen aantonen waarom hun code te vertrouwen is. Maar daar lijkt bijna niemand interesse in te hebben.

Wetten die ervoor moeten zorgen dat code veilig is.... = de oplossing van een bureaucraat.

Overigens speelt dit in meer dan alleen software. Daarvoor bestaan dan weer certificaten. Die zijn ook weer een resultaat van controles. Door mensen en soms ook steeksproefgewijs.

Succes met gamen, algemeen copyrighted mediagebruik en andere van die zaken. Veel partijen gaan inderdaad niet aantonen waarom hun code te vertrouwen is. Ze gaan die code namelijk heel bewust niet vrijgeven. Wil je die zaken niet op jouw systeem, prima, dan gebruik je die niet. Smartphones zitten er ook vol mee, baseband code, binary blobs en wat al niet meer.

Zelfde met printers, ander merk kopen dat wel doet wat je wilt. Heb je werkelijk om die reden bij voorbaat al een volledige IT omgeving opgebouwd, waar geen enkele printer voorkomt van HP, Samsung of Xerox?

Het probleem daarbij is dat het kennelijk nog normaal is om 16 jaar oude code te blijven gebruiken, terwijl dat niet zomaar redelijk is als kennis over veilig programmeren en zelfs wetgeving heel veel strenger zijn geworden. Maar zelfs dan vinden gebruikers als bedrijven het kennelijk wel normaal om computers na een aantal jaar af te schrijven (financieel voordelig) maar niet om software af te schrijven?

Ik geloof echt niet dat dat de kwaliteit van software zou verbeteren. Er is enorm veel software in gebruik die ouder is dan 16 jaar. Die allemaal vervangen komt met een gigantische kost, enerzijds om die te vervangen en anderzijds om de ontwikkelaars nog meer dan nu al het geval is om te scholen in steeds nieuwe technieken. We hebben nu al te weinig ontwikkelaars om te schrijven en te onderhouden wat er geschreven en onderhouden moet worden, dus we gaan vooral ontwikkelaars hebben die onder nog grotere tijdsdruk code moeten schrijven in een taal/framework/... dat relatief nieuwer voor hen is. Niet echt mijn idee van een solide basis.

a type of security that is probably the preferred choice for people with Down syndrome

Klinkt niet bijzonder serieus te nemen. Wie is deze "meest intelligente computeringenieur"?

Ik snap ook de logica niet helemaal... De meeste aanvallen gaan uiteraard tegen Windows. Dat bewijst niet dat Windows slechter is maar is logisch door het marktaandeel.

(Ik geloof trouwens zelf wel dat BSD veiliger is en in sommige opzichten beter in elkaar steekt, maar dat zie ik met deze argumenten niet bewezen)

Android heeft meer dan 50% marktaandeel. macOS en iOS en ChromeOS hebben ook een marktaandeel.

Dus die 83% kan net niet verklaard worden door het marktaandeel, maar enkel dat het gewoon supersimpel is om kwetsbaarheden in windows te vinden.

Het is wel een redelijk groot probleem wanneer er jaarlijks 160 miljoen malware programmas geschreven worden. Het betekent dat windows, dat eigenlijk van in het begin al geen enkele bestaansreden had, honderden miljoenen mensen het slachtoffer maken van cybercriminelen. Terwijl dit aantal rond 5% zou zijn geweest indien iedereen BSD of Linux systemen zou gebruiken. Bovendien zit je met windows met het probleem dat één malware werkt op het systeem van iedere windows gebruiker. Terwijl met Linux heb je veel verschillende distro's en een malware schrijven is dus minder aantrekkelijk want hij gaat op veel systemen niet eens werken..

Ik vind het persoonlijk vreemd dat Microsoft hier niet voor verantwoordelijk gesteld wordt. Als ik een wetgevende macht zou zijn, zou ik ervoor zorgen dat Microsoft voor al deze extra cyber slachtoffers jaar lijks miljarden dollars mag afleggen, als compensatie voor een situatie waar zij de enige schuldige in zijn.

Rust is ook niet zaligmakend.

In Rust kun je nog steeds vieze dingen doen. Geen idee waarom het continu als "The Silver Bullet" wordt gepresenteerd.

Het probleem wordt enkel verplaatst in plaats van opgelost. Eigenlijk zelfs verergerd, want het hele team moet Rust of ander programeertaal X leren in plaats van de pitfalls van de huidige gebruikte programmeertalen in hun hoofd te stampen.

Talen zoals Rust kun je geen drivers in schrijven, kijk maar naar de status van GPGPU in Rust. Dingen die niet “mogen” in bepaalde talen (zoals directe toegang tot geheugen of directe toegang naar apparaten) zijn wel degelijk nodig in drivers en een groot deel van de wereld heeft echt geen zin om extra hardware of uiteindelijk energiekosten in te voeren in geval van een theoretische aanval. Veel problemen zitten in de libraries die je ook op supercomputers snel wilt laten draaien, Rust en Python sloop je er dan liever uit.

Daarnaast wil je ook niet dat drivers in de weg komen zitten. Rust gaat zowel tijdens compile time alsook in runtime checks gaan uitvoeren die de taal veel trager laat worden

Je kunt prima drivers schrijven in Rust. De vraag is alleen wie dat gaat doen en of dat dan alleen voor nieuwere hardware gedaan wordt.

In C++ zijn er al jaaaaaren libraries met safe varianten van buffer access/managment.
Alle ruwe buffers (arrays) vervangen door std::array, std::vector en nieuwe iterator notaties

Bijv als je alleen wil lezen:
for (const auto& entry : buffer)

En dan ben je al een heel end op weg. En dit zijn in mijn ervaring meestal makkelijke wijzigingen met weinig tot geen risico. Zelfs bij gebrek aan unit tests (die er natuurlijk zouden moeten zijn).

PS. Volgens mij heb je in "C" ook toegang tot "safe" varianten van stringcpy, mempcy etc die ook al aardig helpen.

Is die oplossing al ouder dan 16 jaar? Zoniet, dan verklaart dat waarom dit gebeurt.

Is die software die gebruikt wordt dan toch al 16 jaar oud onder het motto , if it ain’t broke, don’t fix it…. anders dan zo nu en dan een nieuw uiterlijk met wat gladdere knoppen.

Na een aantal jaar zou je die in een virtual omgeving moeten laten draaien met niets meer of minder dan alleen de rechten toekennen die het nodig heeft.

Alleen als het in windows zelf ook allemaal niet zo koosjer is , wordt het beetje water naar de zee dragen.
nieuws: Microsoft waarschuwt voor nieuwe kwetsbaarheid in printsysteem Window...

Ik pleit/eis dat er een kale versie met klassieke gui komt. Minder franje betekent meer aandacht voor wat er eigenlijk onder de motorkap zit.

Het beveiligings-lek bestaat al 16 jaar. Waar ben je dan nu over aan het klagen? Dat er toen andere software gebruikt werd? Of dat ontwikkelaars oude code niet zomaar porteren als er geen vraag naar is? Of misschien dat klanten zich afhankelijk maken van oude software en dat kennelijk prima vinden?

Niet, net zo iets als dat we ook weten dat we geen spelfouten moeten maken, en die toch steeds nog gemaakt worden.

En de talen die er zijn die meer aan buffer overflow protectie doen, daarvan wordt vroeg of laat - zoals meerdere ook aangeven - systeem API's gebruikt. En die systeem API's zelf zijn ook gewoon software, geschreven door mensen die ook fouten kunnen maken. Daarbij weet ik niet of er programmeertalen zijn die en buffer overflow bescherming hebben en als low-level driver gebruikt kunnen worden.

Overigens is in de afgelopen 20 jaar ook best veel gedaan door o.a. Microsoft om 'data' en 'code' te scheiden (bijv. data execution protection/DEP, markers in de stack, markers aan het eind van buffers, 'safe' varianten van Windows APIs). Buffer overflows zitten normaal in het data deel van je programma en zou geen invloed moeten hebben op het executie deel en al helemaal niet een 'elevation van rechten' waardoor een normale gebruiker plots admin rechten krijgt. Omdat drivers vaak 'hoog in de rechtenboom' zitten, speelt dat 'elevation' niet (zo), maar speelt naast de gebruikte programmeertaal ook het onderliggende systeem een grote rol (hoe het met bufferoverflows om gaat). En dan geldt dat de code-base te veel, te groot, te oud is, om dit probleem ooit uit te bannen. Al zou je alles van de grond af opnieuw schrijven, dan nog is het de vraag of je een foutloos systeem krijgt (geschreven door mensen die fouten maken).

Tsja, waarom een printer driver dan ook zoveel rechten nodig heeft om een beetje netwerkverkeer te generen, je weet het niet.

Ik kan het verkeerd hebben, maar volgens mij draaien alle drivers in kernel mode en dus hebben ze helemaal niets van doen met user security. Drivers moeten rechtstreeks de hardware kunnen aansturen.

Edit: printerdrivers draaien normaal dus niet in kernel mode.

[Reactie gewijzigd door Ablaze op 21 juli 2021 21:52]

Tegenwoordig draaien veel drivers voor usb-apparaten in user-mode (umdf), maar zestien jaar geleden stond dat nog in de kinderschoenen.

Ik kan niet uit de beschrijving halen of het gaat om een kernel driver. Volgens mij is het overnemen van een als administrator draaiende service ongeveer net zo kwalijk.

Het probleem zit vooral in de onnavolgbare en rommelige softwaredistributies die veel van dit soort fabrikanten bij hun producten meeleveren. Op een of andere manier wordt bij dit soort producten vaak de voorkeur gegeven aan het meeleveren van 200Mb aan rommel in plaats van een minimale driver en te vertrouwen op de ingebouwde functionaliteit van het besturingssysteem.

Er is een policy om kernel printer drivers te verhinderen nog te installeren.

https://admx.help/?Catego...ing::KMPrintersAreBlocked

https://support.microsoft...93-e6ad-a32a-713699695a0d

Windows Server 2003 and later versions include a policy that blocks Kernel mode print drivers because Kernel mode print drivers can cause the computer to display blue screen errors.

Toevoeging, in de desktop variant is het vanaf Vista.

Uit de bron van bovenstaand Tweakers artikel:

Whether you are configuring the printer to work wirelessly or via a USB cable, this driver gets loaded. In addition, it will be loaded by Windows on every boot:
This makes the driver a perfect candidate to target since it will always be loaded on the machine even if there is no printer connected.

It seems that HP didn’t develop this driver but copied it from a project in Windows Driver Samples by Microsoft that has almost identical functionality; fortunately, the MS sample project does not contain the vulnerability.

An exploitable kernel driver vulnerability can lead an unprivileged user to a SYSTEM account and run code in kernel mode (since the vulnerable driver is locally available to anyone). Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.

We hebben dus een 16 jaar oude MS driver waar HP aan geprutst heeft om er zijn eigen sausje over te gieten waardoor er nu een lek in zit dat zich installeert als een kernel printer driver waarbij die driver altijd geladen word, ook al heb je helemaal geen printer. Dat de driver uberhaupt nog geïnstalleerd geraakt gezien Windows die standaard niet meer toelaat, dat is mij nog niet helemaal duidelijk.

Waar het fout loopt is dus 3th party printer fabrikanten echter als MS een harde lijn trekt aan die legacy krijg je artikels op Tweakers "Windows update maakt printers defect".

[Reactie gewijzigd door sprankel op 21 juli 2021 21:22]

Waarschijnlijk omdat gebruikers zoals consumenten en bedrijven al jaren niet zo kieskeurig zijn of software wel veilig is? Kennelijk maakt het niet zo veel voor ze uit of er pas na 16 jaar (of langer) duidelijkheid is dat het lek bleek?

Een printerdriver hoort dan ook helemaal niet in kernelspace te draaien, maar kan heel goed in userspace draaien zoals bij CUPS ook het geval is. Ik heb niet zulke oude printers, maar ik gebruik dan ook geen besturingssysteem dat printers aanstuurt via kernel drivers.

Om dat te bereiken, moeten hackers echter eerst eerst digitaal toegang krijgen tot het systeem van een slachtoffer. Hackers moeten dus eerst op een andere manier de computer van een slachtoffer binnendringen.

Dit klinkt toch een beetje als: hackers moeten eerst in je woning zijn, voordat ze je la met zilveren bestek kunnen openschuiven. Als je toch al in iemands computer zit, heb je niet heel veel meer nodig om bv bestanden te kunnen versleutelen.

Als je als Guest in iemands computer zit kan je niet bij de files van een User of Admin normaliter... En je kan geen script draaien dat die bestanden versleuteld...

Normaliter niet, maar blijkbaar is ook dat niet zo heel moeilijk.

Zijn daadwerkelijk alleen printers van genoemde fabrikanten geraakt door de bug?

wat ik niet snap is waarom een driver gestart wordt voor iets dat ik niet geinstalleerd heb, kan niet bij installatie en voor hoeveel geld dat? Tientallen, honderden? Die allemaal een bug zouden kunnen hebben, lekker veilig.

Hmm...en zoals verwacht geen fixes voor mijn 9 jaar oude HP CM 1312. Althans, ik zie ze niet.

volgens de lijst van NIST is het geen affected product, dus waarom zou je er dan een fix voor verwachten?

dus waarom zou je er dan een fix voor verwachten?

In het artikel:

Er is een 16 jaar oude kwetsbaarheid gevonden in de drivers van HP-, Samsung- en Xerox-printers.

Daarnaast hebben producten vaak verwarrende interne namen en typenummers.

[Reactie gewijzigd door RoestVrijStaal op 21 juli 2021 19:49]

HP is juist enorm consistent in hun nummeringen en het is niet omdat er een kwestbaarheid is gevonden dat ALLE modellen van de volledige periode er gebruik van maken.

Ik heb de laatst beschikbare volledige driverpackage 5.1 voor de CM1312 van 7 oktober 2014 extract en doorzocht en de bewuste ssport.sys-driver zit er NIET in.

Het NIST is trouwens een onafhankelijk overheidsorgaan dat geen enkel voordeel heeft bij het weglaten van ontbrekende modellen.

[Reactie gewijzigd door dasiro op 21 juli 2021 20:30]

Misschien niet een van de getroffen modellen?

Als ik bedenk hoeveel RCE er de afgelopen 16 jaar zijn geweest. Dan is dit AUW.

Dit is een local privesc, geen RCE.

En met een RCE krijgt je lokale rechten.

De vraag is hoelang dit al bekend was voordat het publiekelijk werd?

Dat moet je de NSA vragen, die misbruiken dit natuurlijk al jaren

Mooi dat mijn printer blijkbaar al niet meer vatbaar is ofzo. Samsung ML-2525W. Geïntroduceerd in 2009.