OS X kritische Schwachstelle?!

[scooter010]

Moin!

Ich bin gestern auf interessantes Phänomen gestoßen:

Ich wollte mich per PPPoE ins Inet einloggen. Benutzername eingeben, Passwort Feld leer gelassen weil es kein PW gibt. Damit konnte aber OSX nix anfangen denn das Modem, welches sonst über ein Router die Zugangsdaten erhält, loggt sich ja sonst auch ein.
Ich habe grade erst angefangen bissle C++ zu tippen und gelesen, dass ein "Nullbit" gibt (\0). Ich habe dies eingegeben und plötzlich gings. Scheinbar hat OSX dieses Nullbit angenommen und denn ein leeres PW gesendet.
Aber wenn sich OSX ein Nullbit unterschieben lässt, lässt es sich auch anderes Unterschieben?!

 

[MrNase]

Vielleicht denkt OS X aber auch, \0 sei das Passwort und versucht es deswegen an das Modem zu übermitteln?

 

[scooter010]

ne, das Passwort ist aber nicht gesetzt, gibt kein PW. Vl lässt sich auch der Loginserver des DSL Anbierters das Nullbit unterschieben, aber auf jedenfall lässt sich da jmd das Nullbit unterschieben, denn das PW ist definitiv "" und nicht "\0" (jeweils ohne die Anführungszeichen^^).

Frage ist, verhält sich euer Tiger bis aufs heutige patch aktueller patchstandt auch so? Muss gucken ob es mit dem heutigen patch auch immer noch geht.

 

[NEOCHI]

Das hat was mit dem Unix unterbau zu tun, dort wird eine Nicht gesetztes Password anders bahandelt als bei einer Windows kiste oder anscheinend auch deinem Modem. Das Nullbyte ist nun wahrscheinlich das was eben einem "" in deinem Modem entspricht. Interessant wäre was MacOS dem Modem für ein PW schickt wenn dieses "" ist.
Im Prinzip ist es sinnvoller ein PW zu setzen, auch wenn es nur 1234 istm, als keines zu haben.

 

[scooter010]

Das klingt logisch. Vielleicht wird bei dem Router (oder einer Windows kiste) die PW übermittlung mit dem Nullbyte beendet, welches OSX vl nicht von sich aus sendet, zumindest nicht bei leerem PW-Feld. ich kann nur leider nicht sagen, was osx sendet, da kenn ich mich nicht genug für aus...

 

[NEOCHI]

Setzte mal das PW im Router auf den Bit und dann mach das nochmal. Bzw trage das in einer Windows kiste in der Anmeldung ein wenn der dann auch verbindet sollte das unsere Vermutung bestätigen.

 

[scooter010]

ok mach ich heute im laufe des nachmittag, hab das jetzt grade nicht zur hand. gebe denn heute abend bescheid.

mfg

 

[Rastafari]

das PW ist definitiv "" und nicht "\0"

Diese beiden Strings sind textuell gesehen völlig identisch.

 

[scooter010]

Joa jetzt muss ich ein wenig zurückrudern. Ich habe jetzt mal ausprobiert, was passiert, wenn ich ein beliebiges Passwort eingebe (hätte ich vielleicht vorher überprüfen sollen...) und festgestellt, dass er sich auch verbindet. Liegt denn wohl am Alice Server...
@Rastafari: Warum sind diese Strings identisch?! Ich denke es ist die Aufgabe vom Datentyp "String" Unabhängig vom Inhalt die Daten zu Speichern?! Und wenn ich aus irgendeinem Grund \0 speichern möchte, z.B. als Teil eines Passwortes, denn muss er dies doch auch bewältigen und nicht das Nullbyte für Stringende darin sehen?!

 

[Rastafari]

Warum sind diese Strings identisch?!

Weil NUL-Zeichen in Textdarstellungen redundant sind. Eines ist genausogut wie tausende davon.

Ich denke es ist die Aufgabe vom Datentyp "String" Unabhängig vom Inhalt die Daten zu Speichern?!

Tut er ja auch. Und ein NUL markiert das Ende des Datenstroms (EOF).
(Nicht zu verwechseln mit dem Unix-typischen Zeilenende: Newline, EOL, \x0A)
So ist die Konvention in *allen* Textkodierungen, egal ob ASCII, ANSI, ISO oder UTF.

Und wenn ich aus irgendeinem Grund \0 speichern möchte, z.B. als Teil eines Passwortes, denn muss er dies doch auch bewältigen und nicht das Nullbyte für Stringende darin sehen

Nein. Nicht druckbare Steuerzeichen sind in Kennworten nicht zulässig.
Softwarekomponenten, die solche zulassen sind als fehlerhaft anzusehen.
Kennworte bestehen aus Text und nicht aus 8-bittigen Binärdaten.
Der Unterschied: Text ist immer eine Interpretationsfrage, Binärdaten nie.

Was du da eingegeben hast, ist schliesslich nicht die literale Zeichenfolge "Backslash-Null", sondern die im ANSI-C Standard so vorgegebene, in "backslash-escaped" gehaltene, oktale Darstellung für das Zero-Byte - in hexadezimal ausgedrückt: \x00, oder binär: 00000000
Es gibt keine lesbaren Zeichen dafür, dem ist kein Zeichen zugeordnet und so kann es auch kein Teil eines textuellen Strings sein.
Es ist identisch mit der Formulierung: "empty string". Es ist nur ein String ohne jeglichen Inhalt, sonst nichts. Die Notation "" (die doppelten Anführungszeichen ohne irgendwas dazwischen) meint exakt das gleiche, nur in einer alternativen Schreibweise. Ob dabei nun eines, zwei, zweihundert oder eine ganze Gazillion NUL-Bytes aufeinanderfolgen, die Bedeutung ist im Rahmen einer Textinterpretation immer die gleiche.