Schwachstelle in Ralink-Treibern

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Schwachstelle in Ralink-Treibern

Beitrag von blackice » Donnerstag 29. Januar 2009, 14:00

Gerade über das Debianforum gefunden:
http://www.heise.de/open/Auch-Linux-von ... ung/124626

Weiß jemand, wie es sich mit dem rt2860 des 901 verhält? Nur weil es bisher keinen Fix gibt, heißt das ja noch nicht, dass die Lücke nicht besteht. Falls der Chipsatz betroffen sein sollte interessiert mich insbesondere, ob/wie sich das auf den array.org-Kernel auswirkt? Bei Ubuntu selbst lässt man sich mit Sicherheitsupdates ja gern mal etwas Zeit. Ich hoffe, dass das keine Vorbildfunktion hat.
Kann man in absehbarer Zeit mit einem Update (beider Kernelzweige) rechnen, oder sollte man doch lieber einen Treiber selbst kompilieren?
Ein Kernelmodul zu bauen wäre ja nicht mein Problem, aber wie ich sicherstellen kann, dass der im Kernel integrierte Treiber wirklich deaktiviert wird, weiß ich (noch) nicht.
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
vofiwg
Power User
BeiträgeCOLON 2079
RegistriertCOLON Donnerstag 22. November 2007, 19:36
CONTACTCOLON

Re: Schwachstelle in Ralink-Treibern

Beitrag von vofiwg » Donnerstag 29. Januar 2009, 14:44

Hast du gelesen, dass die Lücke nur den Ad-Hoc-Modus betrifft? Setzt du den überhaupt irgendwo ein?


VoFiWG
Meine Tipps und Hinweise gibt es unter Ausschluss jeglicher Gewährleistung aber mit ganz dollem Daumendrücken. ;)

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Donnerstag 29. Januar 2009, 15:08

Nein, bisher setze ich den Adapter nicht im Ad-hoc-Modus ein. Aber man weiß ja nicht, was noch kommt. Als ich mir den EEE gekauft habe, war ich sogar der Meinung, WLAN gar nicht zu brauchen. Ich "brauche" es auch heute nicht (genau wie den Rest des Geräts), aber es ist schön, WLAN zu haben.
Wenn man dann wirklich mal in der Situation ist den Modus zu brauchen und auch noch daran denken muss, dass da noch eine offene Lücke ist und man sich die ganze Sache besser zweimal überlegt, beruhigt das nicht gerade.

Ungefixte Bugs sind immer blöd, erst recht, wenn ein Fix bereitsteht und die Sache sicherheitskritisch ist.
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
Lorag
Power User
BeiträgeCOLON 1202
RegistriertCOLON Dienstag 18. März 2008, 23:33

Re: Schwachstelle in Ralink-Treibern

Beitrag von Lorag » Donnerstag 29. Januar 2009, 16:13

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513002

inklusive Lösungsvorschlag - Modul müsstest du allerdings selbst bauen. Wobei Ben Hutchings zweifelt, dass der 2860 überhaupt ein Problem hat, da der array of signed char-Fehler in diesem Treiber nicht vorhanden ist.

Solltest du das neu machen wollen, würde ich den git von array.org nehmen, da der neue Ralink-Treiber (1.8) wohl mit dem Eee nicht so richtig will.

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Donnerstag 29. Januar 2009, 17:00

Danke für den Link!
Die Frage wäre jetzt also, ob pFrame->Octet nun signed oder unsigned char ist. Ich habe mir mal den fraglichen Code mit meinen reichlich angestaubten C-Kenntnissen angeschaut, und dort ist es weder als SCHAR, noch als UCHAR deklariert, sondern schlicht als CHAR.
Na toll! Also heißt es, die Compilerspezifikationen herausfinden. Ich gehe mal davon aus/hoffe dass der Treiber mit dem gcc kompiliert wurde. Laut kurzer Google-Recherche bedeutet das auf x86, dass CHAR standardmäßig als SCHAR behandelt wird, was sich aber sicher durch Flags ändern lässt.

Ich stimme Hutchings also eher nicht zu, dass das Problem bei rt2860 nicht bestehen sollte. Allerdings unter der Annahme, dass ein gcc mit Standardkonfiguration verwendet wurde. Irgendwie befriedigt mich das Ergebnis nicht.
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
Lorag
Power User
BeiträgeCOLON 1202
RegistriertCOLON Dienstag 18. März 2008, 23:33

Re: Schwachstelle in Ralink-Treibern

Beitrag von Lorag » Donnerstag 29. Januar 2009, 18:13

Ich sehe in PeerBeaconAndProbeRspSanity keinen wie im Bugreport beschriebenen Konflikt. Das heißt aber nicht viel. ;)

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Donnerstag 29. Januar 2009, 20:17

Ich kann dir nicht ganz folgen. PeerBeaconAndProbeRspSanity finde ich weder im Bugreport noch im Sourcecode der sanity.c des Ralink-Sourcecodes.

Nur um Missverständnisse zu vermeiden, ich meine den Code von hier: http://www.ralinktech.com.tw/data/drive ... .0.tar.bz2

Dort gibt es die eben von mir und auch im Bugreport erwähnte sanity.c mit folgendem Code ab Zeile 326:

CodeCOLON Alles auswählen

if ((pFrame->Octet[0] != IE_SSID) || (pFrame->Octet[1] > MAX_LEN_OF_SSID))
    {
        DBGPRINT(RT_DEBUG_TRACE, "PeerProbeReqSanity fail - wrong SSID IE(Type=%d,Len=%d)\n",pFrame->Octet[0],pFrame->Octet[1]);
        return FALSE;
    }

    *pSsidLen = pFrame->Octet[1];
    memcpy(Ssid, &pFrame->Octet[2], *pSsidLen);
Wenn ich den Bugreport richtig verstehe, ist das Problem, dass sich über pFrame->Octet beliebiger Code einschleusen lässt, sofern die Elemente des Arrays als signed char verarbeitet werden.

Und wenn ich mir die Deklaration anschaue, komme ich in Verbindung mit dem Wissen um das Verhalten von gcc auf x86 zu dem Schluss, dass es sich um signed char handelt:

CodeCOLON Alles auswählen

#111    CHAR          IeType, *Ptr;
#120    Ptr = pFrame->Octet;
Wo ist jetzt mein Denkfehler?
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
Lorag
Power User
BeiträgeCOLON 1202
RegistriertCOLON Dienstag 18. März 2008, 23:33

Re: Schwachstelle in Ralink-Treibern

Beitrag von Lorag » Donnerstag 29. Januar 2009, 23:42

array.org verwendet ralink2860 1.7.1.1, nicht 1.8.0.0. - deshalb habe ich mir den blob von dort angesehen (das kann nun natürlich mein Denkfehler sein): http://git.array.org/?p=array/ubuntu-in ... b751327c46

Da finde ich die im Bugreport erwähnten if-Abfragen mit dem integer-Problem eben nicht. Der PeerBeaconAndProbeRspSanity (ab Zeile 245) sieht komplett anders aus - hat aber imho dieselbe Funktion. Ansonsten finde ich ebenfalls die Info: pframe ist als CHAR definiert und in x86-Systemen mit gcc damit eigentlich signed. Das allein macht ja aber noch nichts, wenn dieser Teil nicht vorhanden ist: (pFrame->Octet[1] > MAX_LEN_OF_SSID).

Der Teil hier (520, 521):

CodeCOLON Alles auswählen

-                    pCfParm->CfpMaxDuration = pEid->Octet[2] + 256 * pEid->Octet[3];
-                    pCfParm->CfpDurRemaining = pEid->Octet[4] + 256 * pEid->Octet[5];
ist allerdings da - und sollte so:

CodeCOLON Alles auswählen

+                    pCfParm->CfpMaxDuration = (UCHAR)pEid->Octet[2] + 256 * (UCHAR)pEid->Octet[3];
+                    pCfParm->CfpDurRemaining = (UCHAR)pEid->Octet[4] + 256 * (UCHAR)pEid->Octet[5];
geändert werden.

Es könnte sein, dass Zeile 389 einen ähnlichen Fehler provoziert ("if(pEid->Len <= MAX_LEN_OF_SSID)"), aber da bin ich echt überfragt. ;)

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Freitag 30. Januar 2009, 09:03

Lorag hat geschriebenCOLONarray.org verwendet ralink2860 1.7.1.1, nicht 1.8.0.0.
Das wusste ich nicht. Danke für die Info! Allerdings komme ich an das gleiche Dokument für Hardy nicht heran und kann nur vermuten, dass in beiden der gleiche Code verwendet wird.
Lorag hat geschriebenCOLONAnsonsten finde ich ebenfalls die Info: pframe ist als CHAR definiert und in x86-Systemen mit gcc damit eigentlich signed. Das allein macht ja aber noch nichts, wenn dieser Teil nicht vorhanden ist: (pFrame->Octet[1] > MAX_LEN_OF_SSID).
Sehe ich genauso.
Lorag hat geschriebenCOLONEs könnte sein, dass Zeile 389 einen ähnlichen Fehler provoziert ("if(pEid->Len <= MAX_LEN_OF_SSID)"), aber da bin ich echt überfragt. ;)
Dazu müsste man den Aufbau des PEID_STRUCT kennen. Auf dessen Korrektheit zu vertrauen, scheint mir aber etwas gewagt.
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
Lorag
Power User
BeiträgeCOLON 1202
RegistriertCOLON Dienstag 18. März 2008, 23:33

Re: Schwachstelle in Ralink-Treibern

Beitrag von Lorag » Freitag 30. Januar 2009, 10:55

blackice hat geschriebenCOLON
Lorag hat geschriebenCOLONarray.org verwendet ralink2860 1.7.1.1, nicht 1.8.0.0.
Das wusste ich nicht. Danke für die Info! Allerdings komme ich an das gleiche Dokument für Hardy nicht heran und kann nur vermuten, dass in beiden der gleiche Code verwendet wird.
Stimmt ein Blick in deine Sig sagt natürlich, das sich das alles auf Hardy bezieht. http://git.array.org/?p=array/ubuntu-ha ... b5e2a637b0 sieht für mich identisch aus. Wenn du magst, clone dir doch einfach mal den hardy-git von array.org und kompilier das Modul mit einem gcc-flag, der CHAR als unsigned definiert - oder mit manuellen Änderungen. Wenn der Treiber dann noch treibt, hast du ja zumindest nix verloren. ;)

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Freitag 30. Januar 2009, 13:12

Da ich mich bisher weder mit Git, noch mit dem Kompilieren eines ganzen Kernels beschäftigt habe, wird das wohl vorerst an meiner Faulheit scheitern, dem abzuhelfen.

Den bestehenden Code zu fixen und ein Kernelmodul zu bauen, sehe ich nicht als Problem. Damit habe ich unter Slax bereits einige Erfahrung und werde es dort auch so machen. Wie schon erwähnt, weiß ich aber nicht, wie ich sicherstellen kann, dass wirklich nur das Kernelmodul verwendet wird, wenn der Treiber schon im Kernel integriert ist. Ist das überhaupt möglich?
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
Lorag
Power User
BeiträgeCOLON 1202
RegistriertCOLON Dienstag 18. März 2008, 23:33

Re: Schwachstelle in Ralink-Treibern

Beitrag von Lorag » Freitag 30. Januar 2009, 16:58

Du kannst dir die Kernelmodule anzeigen lassen, etwa mit cat /proc/modules. Wenn du den Namen des Moduls weißt, kannst du’u auch entfernen (also das Alte): rmmod oder modprobe -r -- oder hab ich die Frage nicht verstanden?
imho sollte es aber reichen, die/das Modul/e neu zu bauen. Dazu bräuchtest du wahrscheinlich auch nicht den ganzen Kernel, sondern nur den lum-Zweig: http://www.array.org/ubuntu/source-build.html -- oder eben den Sourcecode von woanders (aber 1.7.1.1.) und dann insmod <deinmodul>.

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Montag 2. Februar 2009, 20:44

Ich hab mir den Kernel bzw. dessen Umgebung jetzt mal etwas genauer angesehen.
Bisher dachte ich, dass die Treiber direkt in den Kernel kompiliert wurden. Aber es sind ja doch Module. Dann dürfte auch der Austausch kein ernsthaftes Problem darstellen.
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

Benutzeravatar
flux
ENTWICKLER
BeiträgeCOLON 355
RegistriertCOLON Donnerstag 20. März 2008, 16:38

Re: Schwachstelle in Ralink-Treibern

Beitrag von flux » Montag 2. Februar 2009, 21:47

Es würde ja für die allerwenigsten Kernel einen Sinn machen, so ein Device fest in den Kernel zu kompilieren, nicht mal für einen eeePC-Kernel, denn nicht alle eeePCs haben ein RaLink-WLAN verbaut. Nur ein modularer Kernel macht hier Sinn und deckt den größtmöglichen Bereich an Hardware ab. Und die Module können leicht neu einkompiliert werden, wie du ja schon gesagt hast.

flux.

Benutzeravatar
blackice
Power User
BeiträgeCOLON 1079
RegistriertCOLON Dienstag 11. November 2008, 21:46

Re: Schwachstelle in Ralink-Treibern

Beitrag von blackice » Montag 2. Februar 2009, 22:13

Ich habe mir gerade nochmal fluxflux angeschaut. Du stehst ja eigentlich vor genau dem gleichen Problem. Welche Treiberversion verwendest du für rt2860?
Wirst du ein entsprechendes Bugfix anbieten oder ein neu kompiliertes Modul in der nächsten Version anbieten?
Modell: EEE 901 - OS: wattOS beta1 (array.org-kernel)/Slax 6.0.7 (alsa 1.0.18a) - RAM: 2GB (MDT 667MHz) - Zubehör: Akku 8800mAh, SDHC-Card Sandisk UltraII plus USB 8GB

BUTTON_POST_REPLY

Zurück zu

Wer ist online?

Mitglieder in diesem Forum: 1 und 0 Gäste