Nylig brøt nyheten det Omtrent 19 sårbarheter ble funnet i Trecks egenutviklede TCP / IP-stack, som kan utnyttes ved å sende spesialdesignede pakker.
Sårbarhetene som ble funnet, ble tildelt kodenavnet Ripple20 og noen av disse sårbarhetene vises også i Zuken Elmics (Elmic Systems) KASAGO TCP / IP-stack, som deler felles røtter med Treck.
Det bekymringsfulle med denne serien av sårbarheter som er funnet er at TCP / IP Treck stack brukes av mange enheter industriell, medisinsk, kommunikasjon, innebygd og forbruker, fra smarte lamper til skrivere og avbruddsfri strømforsyning), så vel som innen energi, transport, luftfart, handel og oljeproduksjonsutstyr.
Om sårbarheter
Bemerkelsesverdige mål for angrep ved bruk av Treck TCP / IP-stakken de inkluderer HP nettverksskrivere og Intel-brikker.
Inkludering av problemer på TCP / IP Treck stack viste seg å være årsaken til de eksterne sårbarhetene Nylig i Intel AMT- og ISM-delsystemene utnyttet ved å sende en nettverkspakke.
Intel, HP, Hewlett Packard Enterprise, Baxter, Caterpillar, Digi, Rockwell Automation og Schneider Electric bekreftet sårbarhetene. I tillegg til 66 andre produsenter, hvis produkter bruker Treck TCP / IP-stakken, ennå ikke har svart på problemene, kunngjorde fem produsenter, inkludert AMD, at deres produkter ikke var gjenstand for problemer.
Problemer ble funnet i implementeringen av protokollene IPv4, IPv6, UDP, DNS, DHCP, TCP, ICMPv4 og ARP, og ble forårsaket av feil behandling av parametrene med datastørrelsen (ved hjelp av et felt med en størrelse uten å kontrollere den faktiske størrelsen på dataene), feil når du kontrollerte inngangsinformasjonen, dobbelt minne ledig, lest fra et område utenfor bufferen , heltalloverløp, feil tilgangskontroll og problemer med å behandle strenger med nullseparator.
Virkningen av disse sårbarhetene vil variere på grunn av kombinasjonen av kompilerings- og kjøretidsalternativer som brukes når du utvikler forskjellige innebygde systemer. Dette mangfoldet av implementeringer og mangelen på synlighet i forsyningskjeden har forverret problemet med å nøyaktig vurdere virkningen av disse sårbarhetene.
Kort sagt, en uautentisert ekstern angriper kan bruke spesiallagde nettverkspakker for å forårsake nektelse av tjenesten, avsløre informasjon eller utføre vilkårlig kode.
De to farligste problemene (CVE-2020-11896, CVE-2020-11897), som er tildelt CVSS nivå 10, tillater en angriper å kunne utføre koden sin på enheten ved å sende IPv4 / UDP- eller IPv6-pakker på en bestemt måte.
Det første kritiske problemet vises på enheter med støtte for IPv4-tunneler, og det andre på IPv6-aktiverte versjoner utgitt før 4. juni 2009. Et annet kritisk sårbarhet (CVSS 9) er tilstede i DNS-resolveren (CVE-2020-11901) og tillater koden som skal utføres ved å sende en spesiallaget DNS-forespørsel (problemet ble brukt til å demonstrere Schneider Electric UPS APC-hack og vises på enheter med DNS-støtte).
Mens andre sårbarheter CVE-2020-11898, CVE-2020-11899, CVE-2020-11902, CVE-2020-11903, CVE-2020-11905 le tillat å kjenne innholdet ved å sende pakker spesiallaget IPv4 / ICMPv4, IPv6OverIPv4, DHCP, DHCPv6 eller IPv6 minneområder i systemet. Andre problemer kan føre til tjenestenekt eller lekkasje av gjenværende data fra systembuffere.
De fleste av sårbarhetene ble løst på Treck 6.0.1.67-utgivelse (CVE-2020-11897 utgave løst på 5.0.1.35, CVE-2020-11900 på 6.0.1.41, CVE-2020-11903 på 6.0.1.28, CVE-2020-11908 på 4.7).
Siden utarbeidelse av firmwareoppdateringer for bestemte enheter kan være tidkrevende eller umulig ettersom Treck-stakken har blitt levert i over 20 år, har mange enheter vært uten tilsyn eller plagsomme å oppdatere.
Administratorer rådes til å isolere problematiske enheter og konfigurere normalisering eller blokkering i pakkeinspeksjonssystemer, brannmurer eller rutere fragmenterte pakker, blokkerer IP-tunneler (IPv6-i-IPv4 og IP-i-IP), blokkerer «kildesending», muliggjør inspeksjon av feil alternativer i TCP-pakker, blokker ubrukte ICMP-kontrollmeldinger (MTU Update og Address Mask).
Jeg var bare med gruvedrift og PCen min ble skrudd sammen, eller så sa de til meg: Jeg kan fikse det personlig, ellers må jeg ta det med laptop reparasjon