Hotmodell och egenskaper för sårbarhetsbedömning i Linux-kärnan

Linus Torvalds har godkänt ett dokument som reglerar processerna för hantering av säkerhetsrelaterade fel, definierar hotmodellen och förklarar vilka fel i kärnan som tolkas som sårbarheter, samt behandlar åtgärder vid fel som upptäckts med hjälp av AI. Dokumentet har utarbetats av Willy Tarreau, skaparen av HAProxy och en långvarig utvecklare av Linux-kärnan, som ansvarat för underhållet av flera stabila kärnversioner. Som grund har man använt de överenskommelser som uppnåtts under diskussioner kring nyligen identifierade kritiska sårbarheter i kärnan (1, 2, 3, 4), som avslöjades före publiceringen av korrigeringar och för vilka man tack vare AI kunde skapa fungerande exploateringsverktyg omedelbart.

Huvuddelen av säkerhetsrelaterade fel bör hanteras offentligt för att attrahera så många som möjligt och finna den mest optimala lösningen. Endast akuta meddelanden om lätt utnyttjande sårbarheter som utgör ett hot mot många användare och som möjliggör utökade privilegier eller funktioner bör skickas till en separat privat e-postlista.

Sårbarheter som identifierats med hjälp av AI-assistenter bör alltid diskuteras offentligt, eftersom sådana problem ofta upptäckts samtidigt av flera forskare. Det är dock inte nödvändigt att avslöja exploatet i rapporten – det räcker att nämna att det finns och att överlämna det på ett privat sätt som svar på en begäran från den som underhåller.

Det finns särskilda regler för överföring av rapporter skapade med hjälp av AI-assistenter. Det skickas mycket sådana rapporter, och de kan ibland leda till att fel upptäckts i dåligt granskade kodavsnitt, men administratörer ignorerar ofta dem på grund av låg kvalitet och felaktigheter. De viktigaste kraven för rapporter skapade med AI:deltagande är:

• Kortsiktig, utan överflöd, med en tydlig redogörelse för kärnan och viktiga detaljer i början.
• Bara ren text utan Markdown-taggar och dekoration.
• Förståelse av hotmodellen och specificering av verifierade fakta (till exempel, 'felet tillåter vilken användare som helst att få CAP_NET_ADMIN'), snarare än teoretiska spekulationer och antaganden om konsekvenserna av sårbarheten.
• Innan du skickar rapporten måste du noggrant testa funktionaliteten hos den exploiten som skapats via AI, och verifiera möjligheten att återge problemet.
• Att involvera AI för att utveckla och testa lösningen på det identifierade problemet.

Enligt statistik från följdsystemet, är de flesta felrapporter som skickas in som en åtgärd för sårbarheter inte sådana, och bör behandlas i vanlig ordning som vanliga fel. För att särskilja sårbarheter från vanliga fel har en hotmodell för Linux-kärnan beskrivits. Bland de möjligheter och garantier, vars överträdelse kan betraktas som en sårbarhet:

• Isolering på användarnivå: filåtkomst endast för ägaren, processminne är otillgängligt för andra användare, ptrace är förbjudet för andras processer, isolering av IPC och nätverkskommunikation.
• Skydd baserat på möjligheter: utan CAP_SYS_ADMIN kan man inte ändra kärnkonfigurationen, minne, systemets tillstånd, utan CAP_NET_ADMIN kan man inte ändra nätverksinställningar eller fånga trafik, utan CAP_SYS_PTRACE kan man inte spåra andra användares processer.
• Namnrymd för användaridentifierare (CONFIG_USER_NS) möjliggör för oprivilegierade användare att skapa sina egna isolerade miljöer, som inte kan påverka det globala namnrymden, till exempel ändra tiden, ladda moduler och montera blockenheter.
• Avlusningsgränssnitt (\/proc\/kmsg, perf, debugfs), genom vilka man kan få tillgång till konfidentiell information, är endast tillgängliga efter uttryckligt tillstånd från administratören.

Möjligheter som inte betraktas som sårbarheter:

• Användning av föråldrade kärngrenar.
• Kompatibelt byggande med aktiverade alternativ för utvecklare eller osäkerhetsminskande alternativ (t.ex. CONFIG_NOMMU).
• Inställningar i sysctl, kommandoradsalternativ, filsystemtillgångar, möjligheter som är osäkert inställda, eller att ge oprivilegierade användare åtkomst till privilegierade gränssnitt (t.ex. skrivåtkomst till procfs och debugfs).
• Problem i funktioner som är avsedda för utveckling och avlusning av kärnan, såsom LOCKDEP, KASAN och FAULT_INJECTION, som inte är avsedda att ingå i produktionskonfigurationer.
• Problem i drivrutiner, moduler och subsystem som finns i STAGING-sektionen eller som är märkta som experimentella, osäkra eller icke-fungerande.
• Användning av tredjeparts kärnmoduler eller oofficiella kärnversioner.
• Krav på överdrivna behörigheter, såsom behovet av att utföra åtgärder med root-rättigheter eller av en användare som har rättigheter som CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO och CAP_SYS_MODULE.
• Teoretiska attacker som kräver laboratorieförhållanden, miljarder försök, emulering eller modifiering av hårdvara, oproportionerliga kostnader och orealistiska konfigurationer (t.ex. system med tiotusentals CPU-kärnor).
• Omvägar kring skyddsmekanismer (t.ex. ASLR) utan att visa ett exploitalternativ. Brist på argumentkontroller och felkoder utan uppenbara konsekvenser.
• Oplanerade informationsläckor som inte kontrolleras av angriparen, såsom restdata i felmeddelanden och läckor av kärnminnesadresser/pointer utan direkt möjlighet till utnyttjande.
• Fel vid montering av skadade diskavbilder om drivrutinen inte anges som lämplig för användning med osäkra enheter. Problem med diskavbilder som upptäcks och åtgärdas genom körning av verktyget fsck.
• Attacker som kräver fysisk åtkomst till hårdvaran, modifiering av hårdvara eller anslutning av hårdvaruenheter, såsom kort för DMA-attacker och logiska analyzatorer, om systemet inte specifikt är konfigurerat för att skydda mot sådana attacker (IOMMU).
• Regressioner med funktionalitet och prestanda som kan åtgärdas genom att justera rättigheter och gränser.

Källa: opennet.ru