base64 decoder is overly tolerant #69
Comments
|
Hello,
What makes you say that non-canonical Base64 encodings are “incorrect”?
The current validns behavior is consistent with the “be conservative in what you do, be liberal in what you accept from others” principle.
On the other hand, section “3.5. Canonical Encoding" of RFC 4648 says:
In some environments, the alteration is critical and therefore decoders MAY chose to reject an encoding if the pad bits have not been set to zero. The specification referring to this may mandate a specific behaviour.
Do you have good arguments that this applies here? It is not self-evident to me.
\Anton.
… On 17 May 2018, at 00:05, Peter van Dijk ***@***.***> wrote:
Given a correct zone file:
; <<>> DiG 9.11.2 <<>> axfr +onesoa minimal.com @127.0.0.1 -p 5300
;; global options: +cmd
minimal.com. 120 IN SOA ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400
minimal.com. 120 IN RRSIG SOA 13 2 120 20180524000000 20180503000000 12704 minimal.com. uDx8HpRUUkSLuxeckIB0LYQ5HwRobLyrh4+zH9r8aN9KzBNW6VhZbSb/ p1RAkRbVX2w+11tQORhEOyxpieWLVg==
minimal.com. 86400 IN DNSKEY 257 3 13 osdHYQrPEYD9glw8CREAuXXQ2vuSvhKThg9sqW9McBiCcRj+neZU2xsw fTki8/zKKFxRHsAgIQYTwWVE36oBqg==
minimal.com. 86400 IN RRSIG DNSKEY 13 2 86400 20180524000000 20180503000000 12704 minimal.com. EOQJXVGL+gazX/sF5i7BjvzoBKX85hFlXvLUOmpBtxlSjIToOzpbioj4 EtkEqnOyCRM/fRm1dlU/q94S8jhQcw==
minimal.com. 86400 IN NSEC minimal.com. NS SOA RRSIG NSEC DNSKEY
minimal.com. 86400 IN RRSIG NSEC 13 2 86400 20180524000000 20180503000000 12704 minimal.com. KFtt+A+8LIawvljMkF9h6GwNZq7ES0n+I4TGJXlQ5DGSc4qcSopixfY2 j9mVgDfl8FnGIhXHK2YRk/wg0zKqIw==
minimal.com. 120 IN NS ns1.example.com.
minimal.com. 120 IN NS ns2.example.com.
minimal.com. 120 IN RRSIG NS 13 2 120 20180524000000 20180503000000 12704 minimal.com. vOkdWTf9A0j7fJ0FGhZKb53aMX7abbOxomBs4ltc3cv0fzxMeFK+kHLW 0Y3SgEmRC2XugdotQ8RJkVlObq7Cdw==
;; Query time: 7 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Wed May 16 23:41:55 CEST 2018
;; XFR size: 10 records (messages 3, bytes 810)
and a variant with every char at the end (just before ==) bumped up by one:
; <<>> DiG 9.11.2 <<>> axfr +onesoa minimal.com @127.0.0.1 -p 5300
;; global options: +cmd
minimal.com. 120 IN SOA ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400
minimal.com. 120 IN RRSIG SOA 13 2 120 20180524000000 20180503000000 12704 minimal.com. uDx8HpRUUkSLuxeckIB0LYQ5HwRobLyrh4+zH9r8aN9KzBNW6VhZbSb/ p1RAkRbVX2w+11tQORhEOyxpieWLVh==
minimal.com. 86400 IN DNSKEY 257 3 13 osdHYQrPEYD9glw8CREAuXXQ2vuSvhKThg9sqW9McBiCcRj+neZU2xsw fTki8/zKKFxRHsAgIQYTwWVE36oBqg==
minimal.com. 86400 IN RRSIG DNSKEY 13 2 86400 20180524000000 20180503000000 12704 minimal.com. EOQJXVGL+gazX/sF5i7BjvzoBKX85hFlXvLUOmpBtxlSjIToOzpbioj4 EtkEqnOyCRM/fRm1dlU/q94S8jhQcx==
minimal.com. 86400 IN NSEC minimal.com. NS SOA RRSIG NSEC DNSKEY
minimal.com. 86400 IN RRSIG NSEC 13 2 86400 20180524000000 20180503000000 12704 minimal.com. KFtt+A+8LIawvljMkF9h6GwNZq7ES0n+I4TGJXlQ5DGSc4qcSopixfY2 j9mVgDfl8FnGIhXHK2YRk/wg0zKqIx==
minimal.com. 120 IN NS ns1.example.com.
minimal.com. 120 IN NS ns2.example.com.
minimal.com. 120 IN RRSIG NS 13 2 120 20180524000000 20180503000000 12704 minimal.com. vOkdWTf9A0j7fJ0FGhZKb53aMX7abbOxomBs4ltc3cv0fzxMeFK+kHLW 0Y3SgEmRC2XugdotQ8RJkVlObq7Cdx==
;; Query time: 7 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Wed May 16 23:41:55 CEST 2018
;; XFR size: 10 records (messages 3, bytes 810)
validns will validate both. jdnssec-verifyzone will however correctly reject the edited version with invalid base64 encoding.
Using lldb, I can see that (for the SOA, did not look further), decode_base64 in validns will decode both versions to the same 64 bytes, while it should be rejecting the edited version.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#69>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD4v8PMAgWiDjX6dgcAerNh46uZjFOhks5tzKKdgaJpZM4UCHPW>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given a correct zone file:
and a variant with every char at the end (just before
==) bumped up by one:validns will validate both. jdnssec-verifyzone will however correctly reject the edited version with
invalid base64 encoding.Using
lldb, I can see that (for the SOA, did not look further),decode_base64in validns will decode both versions to the same 64 bytes, while it should be rejecting the edited version.The text was updated successfully, but these errors were encountered: