6 ms·

This is probably less severe than it sounds like because of the MSG_PEEK option needed in recvfrom(), which is rarely used.

by antirez 10y ago

kuizu 10y ago
Public information is very thin on the exploitability of this. Are you able to elaborate a little bit where MSG_PEEK might be used? Is it used in the kernel? Only in specific applications?
- antirez 10y ago
  Reading the original link, it looks like the kernel corruption only happens when an user space application uses the recvfrom() syscall using the MSG_PEEK option. MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it. This is not a very common use case, but some research should be done to understand if there is some popular application using it.
  - pjc50 10y ago
    If I've understood this correctly, it turns it into a local privilege escalation opportunity: run a vulnerable application as the user, use the exploit to get code execution in the kernel.
    - zzzcpan 10y ago
      Yeah, but there is still a little bit of explicit usage of recvfrom() with MSG_PEEK https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK And probably more implicit https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK
      - ryan-c 10y ago
        The use in wget seems a little scary.
    - antirez 10y ago
      Yes that's my understanding as well, user space code using a given syscall with given parameters triggers the kernel exploit.
    - CodeWriter23 10y ago
      I believe you've misread the article, first line: > udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic....
  - squarefoot 10y ago
    > MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it I never used the MSG_PEEK flag, but over 15 years ago (maybe it wasnt implemented yet?) I accomplished a similar task by using the SO_REUSEADDR and SO_REUSEPORT flags which worked nicely on Windows too. The goal was to have several UDP "agents" listening on the same port on the same machine (which would normally raise an EADDRINUSE error), all of them examining a packet and acting upon a header contained in that packet. All them would receive a copy of the packet on their respective socket (that was the flags purpose), so that they could filter it and act only if the header contained data relative to that agent. This allowed a very modular approach where once the protocol was defined I could compile only the agent I needed without touching the others.
- daper 10y ago
  This is a flag that the application has to explicitly set when receiving data. Looks like this flag has limited usage based on the description. I've checked with the strace tool few programs that use UDP on my Linux boxes: unbound resolver, ntpd, openvpn. None seems to use it. MSG_PEEK This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data.
  - aduitsis 10y ago
    I've managed to find one case, the net-snmp package uses MSG_PEEK in the SMUX subagent system, heaven knows why. But since the smux socket is practically always bound to localhost, that is not a problem. As far as I can tell, a packet from a non-localhost source may be received, but (obviously) the udp_recvmsg does not get called since the system call is not triggered. Unfortunately, there is a large amount of devices such as home routers, televisions, phones, etc, that are completely impossible to update. So, being aware of cases of software that actually use MSG_PEEK might be useful.
TorKlingberg 10y ago
OpenSSL uses the flag in a couple of places: https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=MSG_PEEK&type= https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=M... Does anyone know what crypto/bio/bss_dgram.c does?
- mcpherrinm 10y ago
  That's an abstraction around datagram IO, for use inside other parts of OpenSSL. I'd assume it's for use with DTLS, which is a less commonly used part of OpenSSL.
IshKebab 10y ago
How do you know it is rarely used? Besides 'rarely' is only slightly better than 'commonly' in this case.

This is probably less severe than it sounds like because of the MSG_PEEK option needed in recvfrom(), which is rarely used.

by antirez 10y ago

This is probably less severe than it sounds like because of the MSG_PEEK option needed in recvfrom(), which is rarely used.

kuizu 10y ago

Public information is very thin on the exploitability of this. Are you able to elaborate a little bit where MSG_PEEK might be used? Is it used in the kernel? Only in specific applications?

antirez 10y ago
Reading the original link, it looks like the kernel corruption only happens when an user space application uses the recvfrom() syscall using the MSG_PEEK option. MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it. This is not a very common use case, but some research should be done to understand if there is some popular application using it.
- pjc50 10y ago
  If I've understood this correctly, it turns it into a local privilege escalation opportunity: run a vulnerable application as the user, use the exploit to get code execution in the kernel.
  - zzzcpan 10y ago
    Yeah, but there is still a little bit of explicit usage of recvfrom() with MSG_PEEK https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK And probably more implicit https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK
    - ryan-c 10y ago
      The use in wget seems a little scary.
  - antirez 10y ago
    Yes that's my understanding as well, user space code using a given syscall with given parameters triggers the kernel exploit.
  - CodeWriter23 10y ago
    I believe you've misread the article, first line: > udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic....
- squarefoot 10y ago
  > MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it I never used the MSG_PEEK flag, but over 15 years ago (maybe it wasnt implemented yet?) I accomplished a similar task by using the SO_REUSEADDR and SO_REUSEPORT flags which worked nicely on Windows too. The goal was to have several UDP "agents" listening on the same port on the same machine (which would normally raise an EADDRINUSE error), all of them examining a packet and acting upon a header contained in that packet. All them would receive a copy of the packet on their respective socket (that was the flags purpose), so that they could filter it and act only if the header contained data relative to that agent. This allowed a very modular approach where once the protocol was defined I could compile only the agent I needed without touching the others.
daper 10y ago
This is a flag that the application has to explicitly set when receiving data. Looks like this flag has limited usage based on the description. I've checked with the strace tool few programs that use UDP on my Linux boxes: unbound resolver, ntpd, openvpn. None seems to use it. MSG_PEEK This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data.
- aduitsis 10y ago
  I've managed to find one case, the net-snmp package uses MSG_PEEK in the SMUX subagent system, heaven knows why. But since the smux socket is practically always bound to localhost, that is not a problem. As far as I can tell, a packet from a non-localhost source may be received, but (obviously) the udp_recvmsg does not get called since the system call is not triggered. Unfortunately, there is a large amount of devices such as home routers, televisions, phones, etc, that are completely impossible to update. So, being aware of cases of software that actually use MSG_PEEK might be useful.

TorKlingberg 10y ago

OpenSSL uses the flag in a couple of places: https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=MSG_PEEK&type= https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=M... Does anyone know what crypto/bio/bss_dgram.c does?

mcpherrinm 10y ago
That's an abstraction around datagram IO, for use inside other parts of OpenSSL. I'd assume it's for use with DTLS, which is a less commonly used part of OpenSSL.

IshKebab 10y ago

How do you know it is rarely used? Besides 'rarely' is only slightly better than 'commonly' in this case.