We never claimed that OpenBSD ping conforms to the
'High Availability ICMP ECHO' RFC.

Jimmy Hess <mysi...@gmail.com> wrote:

> On Tue, Apr 10, 2018 at 3:11 PM, Vadim Zhukov <persg...@gmail.com> wrote:
> > While working on home job for students, I've come across two
> > questionable thingies in ping.c:
> >
> > 1. It sends process PID (well, last 16 bits) to the network.
> >    Maybe I'm a bit paranoid, but this looks like bad idea for me.
> Well, you need a UNIQUE  ID,  because all readers of an ICMP socket are
> going to see All the ICMP echo replies,  including ones that belong to other
> programs  (maybe not ping),  and  possibly some unsolicited replies.
> The standard convention of using the locally-significant PID should be fine.
> The only thought would be that if an adversary knows your process id,
> such as by running  a  "ps"  command on the host  -- since the PID is not
> a secret identifier,  well.
> your adversary could then construct and send  Spoofed replies to
> your ping commands's ICMP ECHO request  from somewhere else on
> the internet,  And knowing your PID,  they would be able to put the
> correct Ident value in their spoofed ECHO REPLY packets.
> However,  there's no real-world case where it's really a concern ---
> unless there were some bug where ping  could misbehave on a malformed reply.
> >    I understand that this worked good when PIDs were 16-bit limited,
> >    because in that case you'll get 100% guarantee two different
> >    ping processes won't overlap. But nowadays we have larger PID
> >    space, so clashes are possible anyway. I propose to go straight
> >    with arc4random().
> Probably using the bottom 16 bits of the PID for most systems is ensuring
> uniqueness,  and  arc4random()  is introducing  unreliability/unpredictability
> in when Ident values may  overlap.....
> Perhaps the ideal situation would be to use the whole  combined
> Ident + Sequence    fields  for matching.
> In other words:  the ICMP REPLY should be discarded unless both  Ident
>  AND  Sequence bits
> in the reply  are within a certain range of values    based on packets sent.
> Then..... populate the whole 32-bit  PID with upper 16 bits to Ident and
> Lower  16 bits  into the   Initial Sequence bits.
> And for reply Match Ident,
> Then  test  if the  Sequence Bits  in the response are in the valid reply 
> range
>  based on    Initial Sequence  --> Final Sequence,
> Or  Initial Sequence +  The count of sent pings   where ping would increment
>  Sequence for each Ping sent,   with consideration for Sequence
> counter wrap/overflow.
> --
> -Jimmy

Reply via email to