0

Is there any way how to makes to recvmsg that listen to UDP to return value that smaller than 0?

I can't run code on the system, only send UDP packet.

Edit:

I have tried the @Ben Voigt offer , sending to this port ICMP Port Unreachable packet to this port and that may trigger ECONNRESET or ECONNREFUSED So I tried this code

from scapy.all import *
send(IP(dst=dst_ip)/UDP(sport=src_port,dport=dst_port))
[here is PCAP file][1] , when I run that code the `recvmsg` has been called(not return -1 of-course)

So no I tried to send ICMP Port Unreachable to that port and hope that recvmsg will fail

from scapy.all import *
send(IP(dst=dst_ip)/ICMP(type=3,code=3)/IP(dst=dst_ip)/UDP(sport=src_port,dport=dst_port))

enter image description here

here is PCAP file but the recvmsg not even called

Kokomelom
  • 143
  • 1
  • 10
  • 1
    Am I correct in assuming that you've been given the task of testing this system? It sounds like its designers have a few things to learn about [DFT](https://en.wikipedia.org/wiki/Design_for_testability), which despite the focus of the Wikipedia article, is a thing for software also.. – Steve Summit Jul 05 '22 at 14:57
  • You can't get `recvmsg` to fail by receiving a packet. That's what causes it to *succeed*. – ikegami Jul 05 '22 at 14:59
  • You *might* be able to force `ECONNRESET` to occur, with an appropriate ICMP packet, although it's unclear whether that would affect the next operation on the socket or only a subsequent send operation. – Ben Voigt Jul 05 '22 at 16:24
  • @BenVoigt Do you mean `ECONNREFUSED` ? How can I do that please with ICMP packet? – Kokomelom Jul 05 '22 at 16:46
  • @Kokomelom: Apparently different platforms could translate ICMP Port Unreachable messages to either `ECONNRESET` or `ECONNREFUSED`. Since both UDP and ICMP are unreliable protocols, all the documentation you can find will only describe what *might* happen, and not be able to tell you what *will* happen. – Ben Voigt Jul 05 '22 at 17:34
  • @BenVoigt Thank you. I tried but I didn't understand how to create a packet (with Scapy) that send `ICMP Port Unreachable` to specific port. – Kokomelom Jul 05 '22 at 18:52
  • The ICMP message doesn't go *to* a specific UDP port, but it will carry in its payload a description of the packet that was discarded. The ICMP message format is described in RFC792: https://www.rfc-editor.org/rfc/rfc792.html https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_unreachable You'll need to create an IP header that spoofs a packet coming from the specific address and port, so you can send back a Destination Unreachable ICMP – Ben Voigt Jul 05 '22 at 18:58
  • Sorry, there's too much magic going on there that's specific to a particular python library for me to speak confidently about that pastebin. You should inspect the result to make sure that concatenation put the spoofed header in the correct place; perhaps it was supposed to be passed into the ICMP object somehow. Also make sure you include at least 8 bytes of spoofed packet payload, and make sure the header fields you left at their default produce something reasonable. Or just send the thing, capture in wireshark, and see what its ICMP dissector says you sent. – Ben Voigt Jul 05 '22 at 19:13
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/246181/discussion-between-kokomelom-and-ben-voigt). – Kokomelom Jul 05 '22 at 20:23
  • @BenVoigt I have edit my post according to your offer. can you please take a look? – Kokomelom Jul 05 '22 at 20:26
  • I assume that 10.8.0.4 is your own computer and 192.168.5.55 is the one you are trying to confuse into returning an error from `recvmsg`? Let us suppose that 192.168.5.55 has sent out a UDP packet coming from port 5555. And the recipient of the packet (the computer owning the destination IP address) cannot deliver it because no process is listening at the destination UDP port. Then that computer would send back an ICMP message containing the headers of the original UDP packet that got dropped. – Ben Voigt Jul 05 '22 at 20:30
  • As a result, the recipient of the ICMP message will match the source IP address and port of the UDP packet that was dropped. So you have to invent a UDP packet "transmitted from the victim" and pretend that your ICMP message is informing the victim about the packet he transmitted. – Ben Voigt Jul 05 '22 at 20:34
  • @BenVoigt Yes, 10.8.0.4 is my own PC and 192.168.5.55 is the target IP . So I must know UDP packet that to victim was send and send it back into the UDP ? that makes it harder – Kokomelom Jul 05 '22 at 20:44
  • Not one sent to 192.168.5.55. One sent by 195.168.5.55. And you may succeed (in causing `recvmsg` to return -1) by using an imagined packet rather than a real packet. But you have to set the packet header captured inside the ICMP message to match this real-or-imagined packet. – Ben Voigt Jul 05 '22 at 20:56
  • @BenVoigt I already do that, I have put the source IP and source port in IP and UDP header as the IP and port that the target device already send a UDP packet ... witch more headers should I put into ? thank you so much! – Kokomelom Jul 05 '22 at 21:02
  • It's wrong in the wireshark screenshot currently in the question. Maybe you changed things since taking that screenshot? – Ben Voigt Jul 05 '22 at 21:04
  • @BenVoigt I remove the packet that came from the target device in the PCAP file. but again , what do you offer? my spoof packet is good but you say that I need to copy all header (IP and PORT) and that will make to `recvmsg` to fail ? – Kokomelom Jul 05 '22 at 21:32
  • The "imagine it was sent and failed" packet inside the Destination Unreachable ICMP cannot be going the same direction as the ICMP itself. – Ben Voigt Jul 05 '22 at 21:35
  • @BenVoigt you talking about that 8 wrote twice the IP of target device (192.168.1.55) ? In the IP layer and on the fake IP layer? What should I need to write instead? That is the IP of the target device. – Kokomelom Jul 05 '22 at 21:38
  • Make your spoof packet (the one you send ICMP to complain about) look like it came from from 192.168.5.55. That means 192.168.5.55 is the source address. The source port must match the socket where the victim is calling `recvmsg`. – Ben Voigt Jul 05 '22 at 21:43
  • @BenVoigt yes. That exactly what I put into the picture. The victim (192.168.1.55) is listen to port 5555 with the `recvmsg` function – Kokomelom Jul 05 '22 at 21:46
  • In your picture, the two lines underneath "Unused: 000000" represent the spoofed packet. Think about what happens when a postal envelope is undeliverable because the recipient moved... the final post office will stamp it "return to sender", and then do they deliver it to the recipient address or the return address? – Ben Voigt Jul 05 '22 at 21:54
  • @BenVoigt So if I understand you as well in the fake packet ( the two lines underneath "Unused: 000000" ) I need to flip the target and source IP and port ?(I already do that) – Kokomelom Jul 05 '22 at 22:09
  • Yes, the fake packet inside the ICMP payload needs to show the victim address and port as its source. – Ben Voigt Jul 05 '22 at 22:13
  • @BenVoigt Thank you, I fliped the source and destination Ip and port in the fake packet inside the ICMP and It's doesn't work...the `recvmsg` didn't call. – Kokomelom Jul 05 '22 at 22:15

1 Answers1

2

If you want recvmsg return -1 for testing, implement your own recvmsg in a shared library and inject it in your program with LD_PRELOAD. See The LD_PRELOAD trick for more details.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271