RADIUS Accounting: Fehlerhaftes Handling von String-Attribut

Forum zu den aktuellen LANCOM Wireless Accesspoint Serien

Moderator: Lancom-Systems Moderatoren

Antworten
stefan.winter
Beiträge: 61
Registriert: 21 Mär 2006, 13:34

RADIUS Accounting: Fehlerhaftes Handling von String-Attribut

Beitrag von stefan.winter »

Hallo,

weiss nicht ob das LANCOM-Forum der richtige Platz ist, aber ich probier's einfach mal hier mit meinem Bug-Report:

Bei Accounting-Paketen bei dem neuen RADIUS-Accounting für WPA (Start, Stop und Interim-Update) werden viele Attribute mit einer zusätzlichen \000 am Ende geschickt (mit Ethereal überprüft, pcap kann ich gern an einen LANCOM Mitarbeiter schicken wenn gewünscht). Das ist zwar nicht unbedingt verboten, kann aber den ein oder anderen RADIUS-Server aus dem Tritt bringen wenn da ein String an der falschen Stelle ein \0 enthält. Ausserdem werden dadurch faktisch falsche Informationen übermittelt: Bei der Called-Station-Id für meine SSID "eduroam" bespielsweise wird dann ...MAC...:eduroam\000 als Wert geschickt, so als ob die SSID nicht eduroam sondern eduroam\000 heißen würde.
Ich habe einen

| LANCOM L-54g Wireless
| Ver. 6.06.0012 / 27.03.2006

Grüße,

Stefan Winter
Weltweites Roaming für Forschung und Bildung
www.eduroam.org
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

leider ist es so, daß einige andere RADIUS-Server sich
auf die Schnauze legen, wenn das NUL-Zeichen nicht
vorhanden ist.

Der Wert für die Called-Station-Id ist RFC3580 entnommen.

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
stefan.winter
Beiträge: 61
Registriert: 21 Mär 2006, 13:34

Beitrag von stefan.winter »

alf29 hat geschrieben: leider ist es so, daß einige andere RADIUS-Server sich
auf die Schnauze legen, wenn das NUL-Zeichen nicht
vorhanden ist.

Der Wert für die Called-Station-Id ist RFC3580 entnommen.
Für die Definition von Attribute Values ist RFC2865 (RADIUS) zuständig, und dort steht auf Seite 24 dass Strings NICHT NUL terminiert werden dürfen. Also verletzt LCOS 6.06 ganz klar das RADIUS-RFC. Wenn andere RADIUS-Server durch korrekte Pakete aus dem Tritt komen, sollte das ganz allein deren Problem sein.
RFC2865 hat geschrieben: Value

The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the Type and Length fields.

Note that none of the types in RADIUS terminate with a NUL (hex
00). In particular, types "text" and "string" in RADIUS do not
terminate with a NUL (hex 00). The Attribute has a length field
and does not use a terminator. Text contains UTF-8 encoded 10646
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
RADIUS implementers using C are cautioned not to use strcpy() when
handling strings.
Grüße,

Stefan Winter
Weltweites Roaming für Forschung und Bildung
www.eduroam.org
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,
Für die Definition von Attribute Values ist RFC2865 (RADIUS) zuständig, und dort steht auf Seite 24 dass Strings NICHT NUL terminiert werden dürfen. Also verletzt LCOS 6.06 ganz klar das RADIUS-RFC. Wenn andere RADIUS-Server durch korrekte Pakete aus dem Tritt komen, sollte das ganz allein deren Problem sein.
Ich weiß nicht, für welchen RADIUS-Server das damals
reingekommen ist. Ich fürchte nur, der kam aus Redmont
und steht damit über allen RFCs :-(

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
Antworten