[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: Link-layer security flaws
From:       noc-wage <wage () IDIRECT ! CA>
Date:       1999-04-29 21:14:22
[Download RAW message or body]

A few months back I wrote an article in KeenVeracity 6 about exploiting
PPP Byte-Stuffing. (Which is what Illuminatus is talking about doing)
The full article is available here:

http://www.t00ned.org/optik/kv/kv6.txt

And I'll paste an excerpt from it:

Explanation of Byte Stuffing

As explained in the PPP frame explanation there is a risk that
certain illegal values will end up in the information of a PPP
frame.  To solve this problem byte-stuffing is used.  In the
case of PPP frames the illegal value is changed to two bytes.
One is the value 01111101 (0x7D) the other is the illegal
character XOR'd with 0x20.  In the case of 0x7E it will become
0x7D, 0x5E.  This also makes any 0x7D which was not added by
the PPP daemon to be encoded in the same manner to avoid
corrupting valid data.  What this means is that a single byte
(for example 0x7E) will be converted into a pair of bytes
(0x7D, 0x5E) but only when encapsulated in PPP frames.
If 4-bytes in the datagram are 0x7E then each of those 4-bytes
will be converted into the 0x7D, 0x5E pair.  This results in
the 4-bytes being turned into 8-bytes when encapsulated in a
PPP frame.  This added data is known as "overhead".

The implications of this is that maliciously engineered packets
could be made to exploit the byte-stuffing method and can
cause a worst case overhead of 100%.  This means that a packet
could literally double in size when encapsulated in a PPP
frame. A 1024-byte ECHO_REQUEST could seem like 2048-bytes.
This means that an attacker requires half the bandwidth to
cause the same amount of disruption.  This also means that if
an attacker is on a PPP connection and is attempting this
attack he will also find that he requires as much bandwidth to
transmit the packets as the victim requires to recieve them.

To test this idea all you need to do is send two packets, one
containing random data.  The second containing only 0x7E.
or any of the following 0x7D, 0xFF all considered illegal
values in datagrams in a PPP frame.
Watch your ppp interface (for linux pppstats -w 1 is good)
and look at the number of bytes.

Below is the actual output of pppstats on my ppp interface
while I'm using linux's ping to send the two packets:

Regular packet using ping's random padding method:
created with: ping -c 1 -s 500 xxx.xxx.xxx.xxx
    in   pack   comp uncomp    err  |    out   pack   comp uncomp     ip
     0      1      0      0      0  |    537      1      0      0      1


Malicous packet padded with 0x7E
created with: ping -p 7e -c 1 -s 500 xxx.xxx.xxx.xxx
    in   pack   comp uncomp    err  |    out   pack   comp uncomp     ip
     0      1      0      0      0  |   1025      1      0      0      1



Illuminatus Primus wrote:
>
> PPP's escape character is '~', and any occurences of this character
> must be escaped.  So, to double the effectiveness of a ping flood,
> pings can be filled with a tilde.  DoS
>
> +----[ On Wed, Apr 28, at 11:34AM(+0200), Otel Florian-Daniel wrote: ]--------------
> | Hello everybody,
> |
> | I'm trying to gather some data about link-layer protocol specific attacks
> | and/or security flaws that can be exploited, e.g. Ethernet is prone to
> | sniffing and MAC address spoofing. Most of the stuff I found so far
> | revolves around Eth. sniffing (how to use it, how to detect it, so
> | on and so forth). But what about other types of attacks and/or
> | link-layers (e.g. broadcast-storm based DoS attack? Are Token Ring, FDDI,
> | ISDN, ATM flawless ?)  Does anybody have some info about this ? Is the
> | topic superfluous/too general ?
> |
> | Many thanks in advance for any reasonable comment and/or pointers,
> |
> |
> | Florian
> |
> | P.S: Maybe is worth stressing more that I'm looking for vendor and
> | protocol independent info and not specific implementation bugs.
> +----[ End Quote ]---------------------------

--
Max Schau  <wage@idirect.ca>/<nocwage@globalserve.net>
KeyID 1024/0F699BD3
"The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one"--Dennis Huges, FBI

[prev in list] [next in list] [prev in thread] [next in thread]