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
> 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.