Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-463

OVN-Kubernetes should not send IPs with leading zeros to OVN

XMLWordPrintable

    • Low
    • None
    • CFE Sprint 225, CFE Sprint 226, CFE Sprint 227
    • 3
    • Rejected
    • False
    • Hide

      None

      Show
      None

      Description of problem:

      If you set a services cluster IP to an IP with a leading zero (e.g. 192.168.0.011), ovn-k should normalise this and remove the leading zero before sending it to ovn.

      This was seen by me on a CI run executing the k8 test here: test/e2e/network/funny_ips.go +75

      you can reproduce using that above test.

      Have a read of the text there:

       43 // What are funny IPs:  
       44 // The adjective is because of the curl blog that explains the history and the problem of liberal  
       45 // parsing of IP addresses and the consequences and security risks caused the lack of normalization,
       46 // mainly due to the use of different notations to abuse parsers misalignment to bypass filters.
       47 // xref: https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4-addresses/   
       48 //     
       49 // Since golang 1.17, IPv4 addresses with leading zeros are rejected by the standard library.
       50 // xref: https://github.com/golang/go/issues/30999
       51 //     
       52 // Because this change on the parsers can cause that previous valid data become invalid, Kubernetes
       53 // forked the old parsers allowing leading zeros on IPv4 address to not break the compatibility.
       54 //     
       55 // Kubernetes interprets leading zeros on IPv4 addresses as decimal, users must not rely on parser
       56 // alignment to not being impacted by the associated security advisory: CVE-2021-29923 golang
       57 // standard library "net" - Improper Input Validation of octal literals in golang 1.16.2 and below
       58 // standard library "net" results in indeterminate SSRF & RFI vulnerabilities. xref:
       59 // https://nvd.nist.gov/vuln/detail/CVE-2021-29923                                                                                                     

      northd is logging an error about this also:

      |socket_util|ERR|172.30.0.011:7180: bad IP address "172.30.0.011" 
      ...
      2022-08-23T14:14:21.968Z|01839|ovn_util|WARN|bad ip address or port for load balancer key 172.30.0.011:7180

       

      Also, I see the error:

      E0823 14:14:34.135115    3284 gateway_shared_intf.go:600] Failed to delete conntrack entry for service e2e-funny-ips-8626/funny-ip: failed to delete conntrack entry for service e2e-funny-ips-8626/funny-ip with svcVIP 172.30.0.011, svcPort 7180, protocol TCP: value "<nil>" passed to DeleteConntrack is not an IP address 

      We should normalise the IPs before sending to OVN-k. I see also theres conntrack error when trying to set this bad IP.

       

      Version-Release number of selected component (if applicable):

      How reproducible:

      Steps to Reproduce:
      1. See above k8 test

      Actual results:

      Leading zero IP sent to OVN

      Expected results:

      No leading zero IP sent to OVN

      Additional info:

              rh-ee-arsen Arkadeep Sen
              mkennell@redhat.com Martin Kennelly
              Anurag Saxena Anurag Saxena
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: