[meta-freescale] [meta-fsl-ppc][PATCH 1/2] net-sctp: CVE-2014-0101
Sona Sarmadi
sona.sarmadi at enea.com
Tue Jan 27 00:09:30 PST 2015
Fixes null pointer dereference when processing authenticated cookie_echo chunk
Reference:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0101
https://bugzilla.redhat.com/show_bug.cgi?id=1070705
Introduced by:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bbd0d59809f9
Signed-off-by: Sona Sarmadi <sona.sarmadi at enea.com>
---
.../linux/files/net-sctp-CVE-2014-0101.patch | 145 +++++++++++++++++++++
recipes-kernel/linux/linux-qoriq_3.12.bb | 1 +
2 files changed, 146 insertions(+)
create mode 100644 recipes-kernel/linux/files/net-sctp-CVE-2014-0101.patch
diff --git a/recipes-kernel/linux/files/net-sctp-CVE-2014-0101.patch b/recipes-kernel/linux/files/net-sctp-CVE-2014-0101.patch
new file mode 100644
index 0000000..6fc5610
--- /dev/null
+++ b/recipes-kernel/linux/files/net-sctp-CVE-2014-0101.patch
@@ -0,0 +1,145 @@
+From 00c53b02cb01976b35d37670a4b5c5d7a6ad3c62 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <dborkman at redhat.com>
+Date: Mon, 3 Mar 2014 17:23:04 +0100
+Subject: [PATCH] net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is
+ AUTH capable
+
+[ Upstream commit ec0223ec48a90cb605244b45f7c62de856403729 ]
+
+RFC4895 introduced AUTH chunks for SCTP; during the SCTP
+handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
+being optional though):
+
+ ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
+ <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
+ -------------------- COOKIE-ECHO -------------------->
+ <-------------------- COOKIE-ACK ---------------------
+
+A special case is when an endpoint requires COOKIE-ECHO
+chunks to be authenticated:
+
+ ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
+ <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
+ ------------------ AUTH; COOKIE-ECHO ---------------->
+ <-------------------- COOKIE-ACK ---------------------
+
+RFC4895, section 6.3. Receiving Authenticated Chunks says:
+
+ The receiver MUST use the HMAC algorithm indicated in
+ the HMAC Identifier field. If this algorithm was not
+ specified by the receiver in the HMAC-ALGO parameter in
+ the INIT or INIT-ACK chunk during association setup, the
+ AUTH chunk and all the chunks after it MUST be discarded
+ and an ERROR chunk SHOULD be sent with the error cause
+ defined in Section 4.1. [...] If no endpoint pair shared
+ key has been configured for that Shared Key Identifier,
+ all authenticated chunks MUST be silently discarded. [...]
+
+ When an endpoint requires COOKIE-ECHO chunks to be
+ authenticated, some special procedures have to be followed
+ because the reception of a COOKIE-ECHO chunk might result
+ in the creation of an SCTP association. If a packet arrives
+ containing an AUTH chunk as a first chunk, a COOKIE-ECHO
+ chunk as the second chunk, and possibly more chunks after
+ them, and the receiver does not have an STCB for that
+ packet, then authentication is based on the contents of
+ the COOKIE-ECHO chunk. In this situation, the receiver MUST
+ authenticate the chunks in the packet by using the RANDOM
+ parameters, CHUNKS parameters and HMAC_ALGO parameters
+ obtained from the COOKIE-ECHO chunk, and possibly a local
+ shared secret as inputs to the authentication procedure
+ specified in Section 6.3. If authentication fails, then
+ the packet is discarded. If the authentication is successful,
+ the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
+ MUST be processed. If the receiver has an STCB, it MUST
+ process the AUTH chunk as described above using the STCB
+ from the existing association to authenticate the
+ COOKIE-ECHO chunk and all the chunks after it. [...]
+
+Commit bbd0d59809f9 introduced the possibility to receive
+and verification of AUTH chunk, including the edge case for
+authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
+the function sctp_sf_do_5_1D_ce() handles processing,
+unpacks and creates a new association if it passed sanity
+checks and also tests for authentication chunks being
+present. After a new association has been processed, it
+invokes sctp_process_init() on the new association and
+walks through the parameter list it received from the INIT
+chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO
+and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
+meta data (peer_random, peer_hmacs, peer_chunks) in case
+sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
+SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set,
+peer_random != NULL and peer_hmacs != NULL the peer is to be
+assumed asoc->peer.auth_capable=1, in any other case
+asoc->peer.auth_capable=0.
+
+Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
+available, we set up a fake auth chunk and pass that on to
+sctp_sf_authenticate(), which at latest in
+sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
+at position 0..0008 when setting up the crypto key in
+crypto_hash_setkey() by using asoc->asoc_shared_key that is
+NULL as condition key_id == asoc->active_key_id is true if
+the AUTH chunk was injected correctly from remote. This
+happens no matter what net.sctp.auth_enable sysctl says.
+
+The fix is to check for net->sctp.auth_enable and for
+asoc->peer.auth_capable before doing any operations like
+sctp_sf_authenticate() as no key is activated in
+sctp_auth_asoc_init_active_key() for each case.
+
+Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
+passed from the INIT chunk was not used in the AUTH chunk, we
+SHOULD send an error; however in this case it would be better
+to just silently discard such a maliciously prepared handshake
+as we didn't even receive a parameter at all. Also, as our
+endpoint has no shared key configured, section 6.3 says that
+MUST silently discard, which we are doing from now onwards.
+
+Before calling sctp_sf_pdiscard(), we need not only to free
+the association, but also the chunk->auth_chunk skb, as
+commit bbd0d59809f9 created a skb clone in that case.
+
+I have tested this locally by using netfilter's nfqueue and
+re-injecting packets into the local stack after maliciously
+modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
+and the SCTP packet containing the COOKIE_ECHO (injecting
+AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.
+
+This fixes CVE-2014-0101
+Upstream-Status: Backport
+
+Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
+Signed-off-by: Daniel Borkmann <dborkman at redhat.com>
+Cc: Vlad Yasevich <yasevich at gmail.com>
+Cc: Neil Horman <nhorman at tuxdriver.com>
+Acked-by: Vlad Yasevich <vyasevich at gmail.com>
+Signed-off-by: David S. Miller <davem at davemloft.net>
+Signed-off-by: Jiri Slaby <jslaby at suse.cz>
+Signed-off-by: Sona Sarmadi <sona.sarmadi at enea.com>
+---
+ net/sctp/sm_statefuns.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
+index dfe3f36..56ebe71 100644
+--- a/net/sctp/sm_statefuns.c
++++ b/net/sctp/sm_statefuns.c
+@@ -759,6 +759,13 @@ sctp_disposition_t sctp_sf_do_5_1D_ce(struct net *net,
+ struct sctp_chunk auth;
+ sctp_ierror_t ret;
+
++ /* Make sure that we and the peer are AUTH capable */
++ if (!net->sctp.auth_enable || !new_asoc->peer.auth_capable) {
++ kfree_skb(chunk->auth_chunk);
++ sctp_association_free(new_asoc);
++ return sctp_sf_pdiscard(net, ep, asoc, type, arg, commands);
++ }
++
+ /* set-up our fake chunk so that we can process it */
+ auth.skb = chunk->auth_chunk;
+ auth.asoc = chunk->asoc;
+--
+1.9.1
+
diff --git a/recipes-kernel/linux/linux-qoriq_3.12.bb b/recipes-kernel/linux/linux-qoriq_3.12.bb
index 48a67c0..874a3f2 100644
--- a/recipes-kernel/linux/linux-qoriq_3.12.bb
+++ b/recipes-kernel/linux/linux-qoriq_3.12.bb
@@ -12,6 +12,7 @@ SRC_URI = "git://git.freescale.com/ppc/sdk/linux.git;nobranch=1 \
file://0004-mnt-CVE-2014-5206_CVE-2014-5207.patch \
file://0005-mnt-CVE-2014-5206_CVE-2014-5207.patch \
file://udf-CVE-2014-6410.patch \
+ file://net-sctp-CVE-2014-0101.patch \
"
SRCREV = "6619b8b55796cdf0cec04b66a71288edd3057229"
--
1.9.1
More information about the meta-freescale
mailing list