From: Tim Wilson <timwilson@mediaone.net>
To: linux-kernel@vger.kernel.org
Cc: torvalds@transmeta.com
Subject: [PATCH] ppp_generic, kernel 2.4.3
Date: Sat, 21 Apr 2001 19:59:24 -0500 [thread overview]
Message-ID: <3AE22CEC.8C000984@mediaone.net> (raw)
An astute observer pointed out that my patch had an extra closing */ in
it. I won't even attempt to explain how that happened, but believe me, I
am suitably mortified. Can I get a mulligan?
Here is the correct patch, along with the original text.
This patch corrects a bug in CCP establishment which can result in a
major security hole.
The bug can cause PPP to NOT install and use a compressor module for
sending, even though the compressor is sucessfully negotiated by CCP.
Since encryption is sometimes implemented as a compressor module (e.g.
MPPE), this bug can cause PPP to send cleartext even though encryption
appears to be sucessfully negotiated.
The bug does not always show up--it depends on the order of CCP messages
exchanged during establishment, and therefore is not deterministic.
The specific problem is handling a sent or received CCP ConfReq. A sent
ConfReq should reset my decompressor; a received ConfReq should reset my
compressor. The original code had this logic exactly reversed.
I am not currently subscribed to the list so please respond directly.
--- drivers/net/ppp_generic.c.orig Sat Apr 21 13:33:00 2001
+++ drivers/net/ppp_generic.c Sat Apr 21 19:41:59 2001
@@ -1967,15 +1967,30 @@
switch (CCP_CODE(dp)) {
case CCP_CONFREQ:
+
+ /* A ConfReq starts negotiation of compression
+ * in one direction of transmission,
+ * and hence brings it down...but which way?
+ *
+ * Remember:
+ * A ConfReq indicates what the sender would like to receive
+ */
+ if(inbound)
+ /* He is proposing what I should send */
+ ppp->xstate &= ~SC_COMP_RUN;
+ else
+ /* I am proposing what he should send */
+ ppp->rstate &= ~SC_DECOMP_RUN;
+
+ break;
+
case CCP_TERMREQ:
case CCP_TERMACK:
/*
- * CCP is going down - disable compression.
+ * CCP is going down, both directions of transmission
*/
- if (inbound)
- ppp->rstate &= ~SC_DECOMP_RUN;
- else
- ppp->xstate &= ~SC_COMP_RUN;
+ ppp->rstate &= ~SC_DECOMP_RUN;
+ ppp->xstate &= ~SC_COMP_RUN;
break;
case CCP_CONFACK:
next reply other threads:[~2001-04-22 0:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-22 0:59 Tim Wilson [this message]
2001-04-22 6:23 ` [PATCH] ppp_generic, kernel 2.4.3 Paul Mackerras
2001-04-22 17:53 ` Tim Wilson
2001-04-23 0:28 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AE22CEC.8C000984@mediaone.net \
--to=timwilson@mediaone.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox