Comments? (Nice to see Mr. Bellovin keeping up the holiday tradition ... :)) -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui
Scott Francis wrote:
Comments?
(Nice to see Mr. Bellovin keeping up the holiday tradition ... :)) Yep.
" Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet." There is no guidelines for specifying how the router will determine if the fragments themselves are dangerous. An attacker may carefully design the evil packet with the expectation of fragmentation, allowing the fragments themselves to be the tool of the attack. It is therefore recommended that all fragment of a packet with the evil bit set should also have the evil bit set when fragmentation is performed by an intermediate router incapable of determining the dangerous nature of the packets. :) -Jack
Hmmm.... Must be 4/1 again. Owen --On Tuesday, April 1, 2003 9:33 AM -0600 Jack Bates <jbates@brightok.net> wrote:
Scott Francis wrote:
Comments?
(Nice to see Mr. Bellovin keeping up the holiday tradition ... :)) Yep.
" Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet."
There is no guidelines for specifying how the router will determine if the fragments themselves are dangerous. An attacker may carefully design the evil packet with the expectation of fragmentation, allowing the fragments themselves to be the tool of the attack. It is therefore recommended that all fragment of a packet with the evil bit set should also have the evil bit set when fragmentation is performed by an intermediate router incapable of determining the dangerous nature of the packets.
:)
-Jack
Nope. I was somewhat concerned at first, then, I realized there was no way this drivel came from Steve Bellovin. Then, I looked at the calendar. Owen --On Tuesday, April 1, 2003 11:32 AM -0600 Jack Bates <jbates@brightok.net> wrote:
Owen DeLong wrote:
Hmmm.... Must be 4/1 again.
Owen
Well, you weren't taking it seriously, I hope. lol
-Jack
Hmmm.... Must be 4/1 again.
Well, you weren't taking it seriously, I hope. lol
http://lists.FreeBSD.org/pipermail/cvs-all/2003-April/001098.html -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" werdna@squooshy.com * "information is power -- share the wealth."
Well, you weren't taking it seriously, I hope. lol
-Jack
------------------------- get it while its hot.... ----------------- Subject: cvs commit: src/sbin/ping ping.8 ping.c src/share/man/man4 inet.4 ip.4 src/sys/netinet in.h in_pcb.h ip.h ip_input.c ip_output.c ip_var.h src/usr.bin/netstat inet.c Date: Tue, 1 Apr 2003 00:21:44 -0800 (PST) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org mdodd 2003/04/01 00:21:44 PST FreeBSD src repository Modified files: sbin/ping ping.8 ping.c share/man/man4 inet.4 ip.4 sys/netinet in.h in_pcb.h ip.h ip_input.c ip_output.c ip_var.h usr.bin/netstat inet.c Log: Implement support for RFC 3514 (The Security Flag in the IPv4 Header). (See: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt) This fulfills the host requirements for userland support by way of the setsockopt() IP_EVIL_INTENT message. There are three sysctl tunables provided to govern system behavior. net.inet.ip.rfc3514: Enables support for rfc3514. As this is an Informational RFC and support is not yet widespread this option is disabled by default. net.inet.ip.hear_no_evil If set the host will discard all received evil packets. net.inet.ip.speak_no_evil If set the host will discard all transmitted evil packets. The IP statistics counter 'ips_evil' (available via 'netstat') provides information on the number of 'evil' packets recieved. For reference, the '-E' option to 'ping' has been provided to demonstrate and test the implementation. Revision Changes Path 1.47 +4 -2 src/sbin/ping/ping.8 1.92 +13 -1 src/sbin/ping/ping.c 1.21 +11 -0 src/share/man/man4/inet.4 1.29 +9 -0 src/share/man/man4/ip.4 1.75 +2 -0 src/sys/netinet/in.h 1.59 +1 -0 src/sys/netinet/in_pcb.h 1.22 +1 -0 src/sys/netinet/ip.h 1.232 +14 -0 src/sys/netinet/ip_input.c 1.181 +28 -1 src/sys/netinet/ip_output.c 1.72 +1 -0 src/sys/netinet/ip_var.h 1.57 +1 -0 src/usr.bin/netstat/inet.c ----- End forwarded message:
The entire thread is more entertaining than just the one post. I particularly like the mention of a cert advisory soon to be released. Although I do agree with the one poster on the thread that did make mention of the fact that doing a cvs commit is going a little far. If the commit was made in earnest. -Jack bmanning@karoshi.com wrote:
------------------------- get it while its hot.... -----------------
Subject: cvs commit: src/sbin/ping ping.8 ping.c src/share/man/man4 inet.4 ip.4 src/sys/netinet in.h in_pcb.h ip.h ip_input.c ip_output.c ip_var.h src/usr.bin/netstat inet.c Date: Tue, 1 Apr 2003 00:21:44 -0800 (PST) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
JB> Date: Tue, 01 Apr 2003 13:06:15 -0600 JB> From: Jack Bates JB> The entire thread is more entertaining than just the one JB> post. I particularly like the mention of a cert advisory JB> soon to be released. I just saw a post forwarded from NTBUGTRAQ to an NT sysadmin list to which I subscribe. JB> Although I do agree with the one poster on the thread that JB> did make mention of the fact that doing a cvs commit is JB> going a little far. If the commit was made in earnest. Nahhhhh. I doubt it'll last until 4.8-R. It'd be interesting to see if it makes it into today's -S, though. :-) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
No the beauty of this is that it is declarative in nature. That means that unless there is some law saying that this transaction is different because it went over this protocol as opposed to that one. And although while Steve is clearly poking fun at the concept that one protocols is different from another - this is true and is becoming more so every day. So this is not so out of touch perhaps. Todd Glassey -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Owen DeLong Sent: Tuesday, April 01, 2003 9:22 AM To: Jack Bates; Scott Francis Cc: nanog@merit.edu Subject: Re: RFC3514 Hmmm.... Must be 4/1 again. Owen --On Tuesday, April 1, 2003 9:33 AM -0600 Jack Bates <jbates@brightok.net> wrote:
Scott Francis wrote:
Comments?
(Nice to see Mr. Bellovin keeping up the holiday
Yep.
" Fragments that by themselves are dangerous MUST have
tradition ... :)) the evil bit
set. If a packet with the evil bit set is fragmented
by an
intermediate router and the fragments themselves are
not dangerous,
the evil bit MUST be cleared in the fragments, and
MUST be turned
back on in the reassembled packet."
There is no guidelines for specifying how the router will
the fragments themselves are dangerous. An attacker may carefully design the evil packet with the expectation of fragmentation, allowing the fragments themselves to be the tool of the attack. It is
determine if therefore
recommended that all fragment of a packet with the evil bit set should also have the evil bit set when fragmentation is performed by an intermediate router incapable of determining the dangerous nature of the packets.
:)
-Jack
participants (8)
-
Andrew Brown -
bmanning＠karoshi.com -
E.B. Dreger -
Eric Gauthier -
Jack Bates -
Owen DeLong -
Scott Francis -
todd glassey