Hallo,
wenn ein lokaler Client einen lokalen DNS-Resolver fragt (127.0.0.1) und dieser bei einer Antwort das „AD“-Flag setzt (authenticated data) um eine erfolgreiche DNSSec-Validierung zu signalisieren, diese Validierung aber nie gemacht hat, würdet ihr das dann als Sicherheitproblem sehen?
Zu beobachten ist das bei dem dnsmasq, der dem aktuellen Debian Wheezy beiliegt. Jede nicht-erste Query an den lokal laufenden dnsmasq beantworte der mit gesetztem AD Flag. Auch wenn der angefragt Name überhaupt ganz und gar nicht per DNSSec geschützt ist!
(Konfiguriert ist er als DNSSec-Proxy, würde die Validierung im Zweifelsfall also auch nicht selbst machen - aber das ist eine andere Geschichte.)
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann
Hi,
On Tuesday, September 16, 2014 23:41:10 Heiko Schlittermann wrote:
wenn ein lokaler Client einen lokalen DNS-Resolver fragt (127.0.0.1) und dieser bei einer Antwort das „AD“-Flag setzt (authenticated data) um eine erfolgreiche DNSSec-Validierung zu signalisieren, diese Validierung aber nie gemacht hat, würdet ihr das dann als Sicherheitproblem sehen?
Das AD flag signalisiert erfolgreiche Validierung, nicht unbedingt DNSSec. Ältere Interpretationen können auch sein: zwei Anfragen nacheinander hatten das selbe Ergebnis.
Zugegeben, der RFC, der dieses Flag auf DNSSec einschränkt ist 10 Jahre alt - trotzdem gibt es genug Implementationen, die kein DNSSec können.
Zu beobachten ist das bei dem dnsmasq, der dem aktuellen Debian Wheezy beiliegt. Jede nicht-erste Query an den lokal laufenden dnsmasq beantworte der mit gesetztem AD Flag. Auch wenn der angefragt Name überhaupt ganz und gar nicht per DNSSec geschützt ist!
(Konfiguriert ist er als DNSSec-Proxy, würde die Validierung im Zweifelsfall also auch nicht selbst machen - aber das ist eine andere Geschichte.)
Offensichtlich kann er entweder kein DNSSec oder ist nicht korrekt konfiguriert (oder buggy).
Ansonsten gilt: wer auf Flags eines Programms am anderen Ende einer Socket vertraut ist selbst schuld.
Konrad
Konrad Rosenbaum konrad@silmor.de (Fr 19 Sep 2014 10:36:19 CEST):
Hi,
On Tuesday, September 16, 2014 23:41:10 Heiko Schlittermann wrote:
wenn ein lokaler Client einen lokalen DNS-Resolver fragt (127.0.0.1) und dieser bei einer Antwort das „AD“-Flag setzt (authenticated data) um eine erfolgreiche DNSSec-Validierung zu signalisieren, diese Validierung aber nie gemacht hat, würdet ihr das dann als Sicherheitproblem sehen?
Das AD flag signalisiert erfolgreiche Validierung, nicht unbedingt DNSSec. Ältere Interpretationen können auch sein: zwei Anfragen nacheinander hatten das selbe Ergebnis.
Zugegeben, der RFC, der dieses Flag auf DNSSec einschränkt ist 10 Jahre alt - trotzdem gibt es genug Implementationen, die kein DNSSec können.
Ich meine, der verwendete DNSMASQ ist durchaus jünger.
Zu beobachten ist das bei dem dnsmasq, der dem aktuellen Debian Wheezy beiliegt. Jede nicht-erste Query an den lokal laufenden dnsmasq beantworte der mit gesetztem AD Flag. Auch wenn der angefragt Name überhaupt ganz und gar nicht per DNSSec geschützt ist!
(Konfiguriert ist er als DNSSec-Proxy, würde die Validierung im Zweifelsfall also auch nicht selbst machen - aber das ist eine andere Geschichte.)
Offensichtlich kann er entweder kein DNSSec oder ist nicht korrekt konfiguriert (oder buggy).
Er kann kein DNSSEC, nur als „Proxy“, dass heisst, er wird auf die Flags vertrauen, die ihm jemand anders schickt. Je nach verwendeter Infrastruktur mag das ok sein.
Aber ich möchte nicht belogen werden! Denn der andere hatte ihm definitiv kein AD geschickt!
Ansonsten gilt: wer auf Flags eines Programms am anderen Ende einer Socket vertraut ist selbst schuld.
Ja, jedoch würde ich bei einer Verbindung zu 127.0.0.1 erstmal von etwas mehr Vertrauenswürdigkeit ausgehen … (Ja, ich weiss, wenn ich 100% sicher sein möchte, dann muss ich selbst validieren. Aber das war nicht der Punkt.)
Der Punkt war: Wie gefährlich ist dieses Verhalten des DNSMASQ? Ist das ein GRAVE Sicherheitsproblem? Oder MINOR? Oder nichts von beidem?
Hi,
On Friday 19 September 2014 14:44:11 Heiko Schlittermann wrote:
Konrad Rosenbaum konrad@silmor.de (Fr 19 Sep 2014 10:36:19 CEST):
Zugegeben, der RFC, der dieses Flag auf DNSSec einschränkt ist 10 Jahre alt - trotzdem gibt es genug Implementationen, die kein DNSSec können.
Ich meine, der verwendete DNSMASQ ist durchaus jünger.
Das mag ein Grund sein, aber ein Hinderniss ist es auch nicht.
Ich hoffe Du wirst entschuldigen dass ich nicht davon schockiert bin - ich bin es (leider) gewohnt immer wieder mit Software zu arbeiten, die 20 Jahre alte Standards nicht korrekt implementiert...
Offensichtlich kann er entweder kein DNSSec oder ist nicht korrekt konfiguriert (oder buggy).
Er kann kein DNSSEC, nur als „Proxy“, dass heisst, er wird auf die Flags vertrauen, die ihm jemand anders schickt. Je nach verwendeter Infrastruktur mag das ok sein.
Aber ich möchte nicht belogen werden! Denn der andere hatte ihm definitiv kein AD geschickt!
Wie gesagt, die alte Interpretation von AD ist: es wurde irgendwie verifiziert - nicht zwingend kryptographisch.
Ich halte das AD Flag für reichlich zweifelhaft - genausogut kann man sich auch darauf verlassen dass gefälschte DNS-RRs das Evil-Bit gesetzt haben.
Ansonsten gilt: wer auf Flags eines Programms am anderen Ende einer Socket vertraut ist selbst schuld.
Ja, jedoch würde ich bei einer Verbindung zu 127.0.0.1 erstmal von etwas mehr Vertrauenswürdigkeit ausgehen … (Ja, ich weiss, wenn ich 100% sicher sein möchte, dann muss ich selbst validieren. Aber das war nicht der Punkt.)
Nur wenn das System am anderen Ende auch das gewünschte Feature (DNSSec) beherrscht. Da das nicht der Fall ist, kann man sich nicht auf AD verlassen.
Der Punkt war: Wie gefährlich ist dieses Verhalten des DNSMASQ? Ist das ein GRAVE Sicherheitsproblem? Oder MINOR? Oder nichts von beidem?
MINOR/SUSPICOUS: setzt ein Flag welches es nicht versteht. Eigentlich müsste es konsequent das AD-Flag löschen, weil es die Grundlagen dahinter nicht versteht und damit das Flag auch nicht verifizieren kann.
Konrad
lug-dd@mailman.schlittermann.de