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 >
