Software AG & ZENNER IoT Solutions besiegeln Partnerschaft
- 19. August 2021
Ein Team von Forschern hat Mitte 2017 Schwachstellen in der Hardware-Architektur von Prozessoren entdeckt. Angreifer können durch das geschickte Ausnutzen dieser Sicherheitslücken Daten auslesen, die der jeweilige Computer im Speicher verarbeitet – also auch Passwörter und geheime Zugangscodes. Meltdown und Spectre sind die Namen der Angriffsszenarien, nach denen sich mit Hilfe von Schadcode die Hardware-Lücken ausnutzen lassen. Insgesamt gibt es drei veröffentlichte Angriffsszenarien:
- CVE-2017-5753 (Spectre 1, Bounds Check Bypass),
- CVE-2017-5715 (Spectre 2, Branch Target Injection) und
- CVE-2017-5754 (Meltdown, Rogue Data Cache Load).
Welche Gefahr geht nun von Meltdown und Spectre auf LoRaWAN-Gateways aus, die in die IT- Infrastruktur eingebunden werden ?
Ein Angreifer muss Schadcode auf dem betroffenen System ausführen können, daher sind diese Lücken für viele Embedded Systeme, Router und LoRaWAN-Gateways unkritisch. Diese Systeme sind als Single User konzipiert. Hat ein User bereits Administratorrechte sind diese Angriffsszenarien nicht nötig. Darüber hinaus sind die in den LoRaWAN-Gateways zumeist eingesetzten ARM-Prozessoren nicht gegen das Meltdown-Szenario anfällig.
Hier eine Übersicht der von uns meist genutzen Gateways und deren Anfälligkeit gegen Meltdown und Spectre.
| Gateway | Architektur | Spectre 1 | Spectre 2 | Meltdown |
|---|---|---|---|---|
| Kerlink Wirnet Station 868 | ARM 926 EJS | Nein | Nein | Nein |
| Kerlink iFemtoCell | ARM Cortex A9 | Ja | Ja | Nein |
| Kerling IBTS | ARM Cortex A9 | Ja | Ja | Nein |
| Multitech Conduit | ARM 926 EJS | Nein | Nein | Nein |
| Wifix Lorix One | ARM Cortex A5 | Nein | Nein | Nein |
Auch der Gateway-Hersteller Kerlink sieht keine Gefahr in Spectre für die IT-Infrastruktur. In seiner Antwort auf unsere Anfrage weist er ebenfalls darauf hin, dass die Angriffsszenarien bei Single User Systemen keinen Nutzen haben.
About Spectre, the vulnerability exists (…), please note that it is not really applicable to our products because:
- to exploit, you would need local code execution
- the profit wouldn’t be so much of an issue, because it would “only” allow access to resources of another user. Also, even in the case of privilege escalation, this doesn’t really make any sense, since almost everything is root on our firmware
Quellen
https://developer.arm.com/support/security-update
Haben Sie Fragen zu IT-Security in Bezug auf LoRaWAN-Infrastrukturen oder zu LoRaWAN im Allgemeinen?
</h3>
</div>
<div class="col-md-3 align-self-center text-md-right">
<a class="btn btn-md u-btn-darkgray g-brd-2 rounded-0" href="/kontakt">Kontakt</a>
</div>
</div>
</section>
</h3>
</div>
<div class="col-md-3 align-self-center text-md-right">
<a class="btn btn-md u-btn-darkgray g-brd-2 rounded-0" href="/kontakt">Kontakt</a>
</div>
</div>
</section>
Über uns
Wir bringen Geräte zum sprechen, stellen sie zu einem Chor zusammen und orchestrieren gewaltige IoT-Ensembles - wir bringen Leben ins Internet der Dinge.