Hlavní navigace

Chyba v Pythonu v knihovně ipaddress

Sdílet

Jan Fikar 3. 5. 2021
Python Autor: Python

Ve standardní knihovně Pythonu ipaddress byla objevena chyba CVE-2021–29921, která je podobná chybě v knihovně netmask v Perlu a npm objevené v březnu tohoto roku. Jde o špatnou validaci IP4 adres, kde číslo začínající 0 má být bráno jako osmičkové. Tedy například 010.8.8.8 má být 8.8.8.8 Kdežto knihovna ipaddress v Pythonu 3.8.0 – 3.10 zahazuje nuly na začátku a vidí tedy 10.8.8.8. Před verzí 3.8.0 adresa, která obsahovala osmičková a decimální čísla, způsobila chybu.

Nyní je možné nesprávné validace zneužít k SSRF (Server-Side Request Forgery), RFI (Remote File Inclusion) či LFI (Local File Inclusion). Na odstranění chyby se pracuje.

(zdroj: bleepingcomputer)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 3. 5. 2021 16:13

    bez přezdívky

    The following constitutes a valid IPv4 address:

    A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0–255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet (byte) in the address. Leading zeroes are not tolerated to prevent confusion with octal notation.

    An integer that fits into 32 bits.

    An integer packed into a bytes object of length 4 (most significant octet first).

    >>>

    ipaddress.IPv4Ad­dress('192.168­.0.1')
    IPv4Address('192­.168.0.1')

    ipaddress.IPv4Ad­dress(3232235521)
    IPv4Address('192­.168.0.1')

    ipaddress.IPv4Ad­dress(b'\xC0\xA8­\x00\x01')
    IPv4Address('192­.168.0.1')

    Changed in version 3.8: Leading zeros are tolerated, even in ambiguous cases that look like octal notation.

    Changed in version 3.10: Leading zeros are no longer tolerated and are treated as an error. IPv4 address strings are now parsed as strict as glibc inet_pton().

    Changed in version 3.9.5: The above change was also included in Python 3.9 starting with version 3.9.5.

    asi by to mělo znovu začít vyhazovat chybu, určitě lepší varianta, než předpokládat, že uživatel chtěl vlastně napsat něco jiného

  • 4. 5. 2021 9:11

    tomas82

    Nejde spíš o to, že by ti nějaký software vnutil řetězec s adresou 010.x.x.x, validátor ho vyhodnotil jako 10.x.x.x, tedy lokální síť, polevil v pozornosti, dovolil další zpracování systémem, který by to přeložil jako 8.x.x.x a provedl pro externí adresu něco, co má dělat jen pro lokální?

    Čili by reálně psal ipv4 adresu jinak než decimálně útočník, který by chtěl zneužít téhle chyby. Zvlášť pokud byla i perlu a npm.

  • 4. 5. 2021 9:28

    Michal Kubeček

    Myslím že kolega tím spíš chtěl říct, že by bylo praktičtější povolit jen "normální" formáty a ne všechny ty speciality, které z historických důvodů podporuje inet_aton().

  • 4. 5. 2021 13:36

    ...

    inet_aton je docela peklíčko, desítky let si ho neseme s sebou, všechny varianty nejsou ani správně ve standardech a je v tom spousty skrytých triků, jednotlivé implementace jsou rozdílné a je to prostě minové pole na podobné chyby.

    S ipv6 tenhle problém již není a je jasně specifikováno jaké může mít varianty.