Logitech dicht lek in Options-software dat sites toegang tot toetsenbord gaf

Logitech heeft donderdag een nieuwe versie van zijn Logitech Options-software aangekondigd waarin het een beveiligingslek in de software heeft gedicht. De kwetsbaarheid gaf websites de mogelijkheid het toetsenbord van gebruikers te benaderen.

Googles Project Zero-onderzoeker Tavis Ormandy berichtte eerder deze week dat Logitech Options een websocketserver op poort 10134 opent, zonder een origin-check toe te passen. De server houdt verband met de sdk van de Craft Crown, een draaischijf voor het draadloze Craft-toetsenbord die bijvoorbeeld specifieke Photoshop-functionaliteit door middel van plugins mogelijk maakt. Logitech Options biedt beheeropties voor toetsenborden en muizen.

De enige authenticatie voor toegang tot de websocketserver is een process id van Windows, maar deze is te bruteforcen, volgens Ormandy. Websites zouden daarmee in staat zijn commando's naar de Options-software te sturen en de draaischijf te configureren.

De beveiligingsonderzoeker vond de kwetsbaarheid op 12 september maar kon geen manier vinden om het beveiligingsteam van Logitech in te lichten. Dat lukte op 18 september toch waarna dat team aan de slag ging om het lek te dichten. Toen dit op 11 december nog niet was gebeurd besloot Ormandy te publiceren. Donderdag maakte Logitech daarop versie 7.00 beschikbaar. Bij de releasenotes meldt het bedrijf alleen dat er 'bug fixes' zijn maar op Twitter benadrukt Logitech dat bij deze versie de kwetsbaarheid is verholpen.

Logitech Craft Crown

Door Olaf van Miltenburg

Nieuwscoördinator

14-12-2018 • 14:08

28

Reacties (28)

28
28
23
1
0
2
Wijzig sortering
Artikel is een tikkeltje onvolledig.
Logitech heeft op 1 okt een nieuwe versie van hun software gereleased, maar hier zat de bug nog steeds in. Nadat Travis ze hier weer op gewezen heeft heeft hij tot 11 dec gewacht en daarna bekend gemaakt op zijn twitter account.
Lol. Als ze zo laks zijn dan denk ik dat er nog wel wat lekjes zitten in die 150Mb aan meuk.
Ik blijf het raar vinden dat bedrijven in hun releasenotes generieke teksten plaatsen en er dan regelmatig achteraan moeten op social-media om, vaak nog steeds deels, tekst en uitleg te geven. Zet het gewoon in de release notes.
Probleem is dat ze denken dat de "gewone mensen" die release notes lezen.
Maar als gewoon persoon heb ik toch meet aan "Fout opgelost die ervoor zorgde dat het programma crashte bij sommige gebruikers" dan een bericht als "Aantal bugfixes"?

Note: staat even los van de inhoud van dit artikelen en gaat meer in o het punt dat release note's zo generiek zijn. Ik erger mij daar ook aan namelijk.
Bij die eerste zin geef je bijvoorbeeld toe dat je een probleem had, tegenover "bugfixes" dat voor de algemene persoon als "verbeteringen" wordt opgevat (of toch voor mij alvast).

Ik gaf graag toe dat ik fouten maakte in changelogs. Uiteindelijk ga je in mails naar je klanten ook niet gewoon de changelog plakken maar gebruik je zowizo simpele taal.

Maarja, marketing.
Bugs komen vaak in een verzamelbakje bij een ontwikkelaar terecht die dan een fix doet, dit wordt getest en komt uiteindelijk in een release terecht. Het is daarbij niet persé zo dat een ontwikkelaar kennis heeft van de functionaliteit rondom die specifieke bug.

Dit maakt het mogelijk moeilijk en tijdrovend voor de ontwikkelaar om een goede beschrijving op te stellen dus beperkt hij/zij zich tot het beschrijven van de technische fix. Dat betekent dat een ander het moet doen en dat is vooral overhead. Daar komt bij dat een heleboel bugs niet zo interessant zijn en het beschrijven ook niet waard zijn.

Voor een bedrijf kan het interessanter zijn om even een berichtje de wereld in te slingeren in plaats van een proces op te tuigen waaraan iedereen zich moet houden en waarvan je de kwaliteit in de gaten moet houden.
Wat een onzin, een bug wordt gemeld en constateert dus een gebrek in de software. Vervolgens moet eerst grondig bekeken worden wat de technisch oorzaak is voordat een oplossing geschreven kan worden. In beide stappen zou je een korte omschrijving van het probleem kunnen noteren. Overigens is de constatering in dit geval al gedaan door mr. Ormandy dus nog minder werk voor Logitech.

Daarnaast zou een fatsoenlijke programmeur de bug/change sowieso kort moeten kunnen omschrijven want als hij versie beheer gebruikt zou hij toch echt een commit message moeten noteren en als je bij een professioneel bedrijf werkt schrijf je hier niet "bug gefixt op".

In ieder geval zou dit niet "moeilijk en tijdrovend" moeten zijn.

De hele reden voor de vage changelog is of ontransparante bedrijfsvoering of incompetentie binnen het ontwikkelteam. Beide kan ik me goed voorstellen bij Logitech.
Hetzelfde in app stores. Bank apps zeggen ook gewoon "diverse bugs gefikst" als release note.

Als ik vanuit mijn werk release notes lees is het vaak een pdf van 50 paginas met bugid en 5-10 regels aan beschrijving per bug.
Pijnlijk dat ze bijna 3 maanden nodig hadden om het lek te dichten.
Dat op zich niet.. logische ontwikkeltijd. Veel problematischer is het feit dat Tavis geen contact kon vinden/krijgen, en dat er geen enkele communicatie vanuit Logitech plaatsvindt. Dit is de reden waarom Tavis tot publicatie overgaat, niet die 'lange' ontwikkeltijd.

[Reactie gewijzigd door Savages op 23 juli 2024 10:00]

Je leest het bericht verkeerd. Op 12/9 vond hij geen manier om ze te contacteren, maar dat is 'm uiteindelijk wel gelukt de 18de. Logitech ging toen ermee aan de slag .
Het feit dat hij het eerder deze maand bekend maakte, is omdat er over het algemeen 90 dagen de tijd gegeven wordt aan bedrijven om een security fix te releasen. Doen ze dat niet op tijd, dan is dat dan maar het probleem van dat bedrijf.
Google deed dit al meermaals met Microsoft, om maar 1 voorbeeldje te geven.
Met iedereen: Project Zero is een Google sponsored initiatief om de veiligheid van het internet te verhogen. White hats (zoals deze) krijgen betaald om lekken te vinden in alle mogelijke applicaties en deze te melden. Het protocol zegt voor alle bugs 90 dagen en dan publiek maken. Dit omdat geen enkele leverancier zit te wachten om bugs te gaan zitten fixen (levert niets op). Dus dan maar naming-and-shaming (ook voor de eigen google producten trouwens).
Dat op zich niet.. logische ontwikkeltijd
I see what you did there :P.

Is inderdaad belachelijk dat het zo lang heeft moeten duren. Helemaal dat er pas actie wordt ondernomen als het publiekelijk gemaakt wordt.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 10:00]

Iets wat ik vaak hoor is dat een security patch eerst getest moet zijn. Maar voor security issues vind ik dat je als bedrijf zo snel mogelijk een patch of workaround moet publiceren zodat iedereen veilig is :) Daarna werk je aan het testen en stabiliseren.

Oh en hij had wel degelijk contact. Maar vanaf 12 september hadden ze dus 3 maand de tijd.
Iets wat ik vaak hoor is dat een security patch eerst getest moet zijn. Maar voor security issues vind ik dat je als bedrijf zo snel mogelijk een patch of workaround moet publiceren zodat iedereen veilig is :) Daarna werk je aan het testen en stabiliseren.
Ik heb toch liever een patch die het security issue fixed maar ook wel grondig getest is, voor het zelfde geld maakt die patch het alleen maar erger waar je dan pas tijdens de grondige test achterkomt en je dan dus al miljoenen pc's kwetsbaarder hebt gemaakt.
Ik bedoel vanaf dat het public is en dus makkelijk geexploit kan worden. Ik heb het over een lek tegenover een lek met een plakker over, natuurlijk wil je gewoon dat gat dichtmaken, maar als ineens iedereen dat lek ziet terwijl je al een plakker klaar hebt, maar dan beslist om die niet direct te plakken, dan hou je je klanten in het donker, en dat is nog minder leuk.
Als je die blog leest is het fixen van het lek nog wel het minst pijnlijke. Het volledige 'Logitech Options' lijkt nogal amateuristisch opgezet. 150 MB applicatie voor het rebinden van een knop en dat zonder security-by-design.
Als je een logitech muis aansluit krijg je al de melding of je even options wil installeren. Het is 150Mb aan onzinnige Logitech rommel die overbodig (en zoals nu ook blijkt: onveilig is). Nog een reden om nooit leveranciersdrivers te installeren. Zit de driver niet in het WHWQ programma met drivers die via het reguliere kanaal komen (of niet in de Linux kernel zitten) dan hoef ik je hardware niet.
Weet niet wat voor OS jij hebt, maar hier wordt er niks automatisch gesuggereerd of geinstalleerd na verbinden van een random hardware component.

? Kom op, beetje TWEAKERS.

[Reactie gewijzigd door Marctraider op 23 juli 2024 10:00]

Windows 10 met een Logitech MX master: connect via Logitech ontvanger: Geeft standaard de popup. Logitech Triathlon: zelfde.
Sorry?
De software van het keyboard openend een websocket, naar het keyboard toe?
Ik zie niet in waarom mijn toetsenbord via een netwerk (ook al is het local) te benaderen moet zijn.
Dat heeft wellicht te maken met de "Flow" functionaliteit:
https://www.logitech.com/...flow-multi-device-control

Hiervoor moeten de apparaten in het zelfde netwerk zitten, dus moet het apparaat vanaf het netwerk benaderbaar zijn. Echter denk ik dat hier wel degelijk een betere oplossing voor is, zoals dat alleen de "options" software met elkaar verbinding maakt tussen de apparaten. Maargoed, ik weet niet hoe de oplossing op dit moment is en of dit er daadwerkelijk meete maken heeft.
Van diezelfde website:
"EASY, FAST, SECURE"

Ironisch als dat inderdaad de bron van dit veiligheidslek zou zijn geweest.
Het is niet zomaar (of enkel en alleen) een toetsenbord

https://tweakers.net/nieu...uring-van-programmas.html
Ik neem aan dat er niet bekend is of hier ook daadwerkelijk misbruik van is gemaakt?
Moderne browsers, zeker Firefox beschermen hier toch al automatisch tegen met CORS? Logitech zal op die socket toch vast niet juist de * waarde gegeven hebben? Meestal ontbreekt de CORS header namelijk.
Ik wil geen toetsenborden zonder draad - en ik wil witte toetsen. 't is zo erg dat ik begin m'n oude toetsenborden te herstellen om maar door te kunnen blijven gaan. Spijtig - maar men is erg fout bezig.

Op dit item kan niet meer gereageerd worden.