Ny Linux-sårbarhed er fundet i programmet 'less'

En sikkerhedsingeniør fra Google har fundet en ny sårbarhed i Linux, hvor en udvidelse til et simpelt standardprogram kan give problemer.

At benytte Linux' 'less'-kommando til at gennemse indholdet af en fil, som man har downloaded fra nettet, kan være en farlig operation. Det skriver Computerworld.com.

En sikkerhedsefterforsker har nemlig fundet ud af, at man, selvom man kun gennemser filen, stadig kan komme til at starte en 'Remote code execution'.

Ved første øjekast ligner det en harmløs kommando, som viser en fils indhold i et terminalvindue og giver brugeren lov til at navigere gennem den. Less giver ikke lov til at ændre noget, hvilket man har andre programmer til.

I stedet har less den fordel, at det kan vise filerne, uden at man er nødt til at bruge computerkraft på at loade hele filen, hvilket især er brugbart med store filer.

På mange Linux-distributioner, også Ubuntu og CentOS, kan less bruges til mange flere filtyper og arkiver, billeder og pdf'er. Det er, fordi less i disse systemer er blevet udvidet med et script kaldet lesspipe, som er afhængig af tredjeparts værktøjer til at køre filer med forskellige udvidelser.

Ifølge sikkerhedsingeniør hos Google Michal Zalewski er less ikke designet med ondsindet input i overvejelserne, og da han kørte et program, som tester svagheder i systemet, på programmet cpio file archiving utility – et program, der støtter lesspipe – identificerede programmet hurtigt en hukommelsesbug, som kan føre til en arbitrær kørsel af en kode.

»Mens det kun er en enlig bug i cpio, er jeg ikke i tvivl om, at de andre lesspipe-programmer er lige så problematiske eller værre,« siger Michal Zalewski.

I øjeblikket kan brugere af Linux beskytte sig ved at fjerne variablerne lessopen og lessclose, hvis de er sat til i deres Linux-systemer. Disse variabler er ifølge Zalewski sat til at køre lesspipe, når less kører filer, som matcher de filer, som lesspipe normalt supporter.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Søren Grønning

Ret beset er der vel tale om GNU less, og ligesom GNU ikke kun er Linux må dette åbne op for at flere systemer er muligt påvirkede af denne usikkerhed.

Computerworld scoper på samme vis i artiklen, som Version2 artiklen ganske slavisk gengiver, når de konkluderer at:

It appears that there's a growing trend of finding vulnerabilities in Linux command-line utilities, which started with the Shellshock flaws found in September in the Bash Unix shell itself.

Det er muligt at GNU værktøjerne findes i Linux, men igen, det gør de altså i en hel del andre systemer også!

Det kan dermed læses som et eksempel på FUD, når Version2 får det til at lyde som om det er Linux, som i Linux specifikt, der er bærer af dette problem, når det nærmere er et led i en samling værktøjer benyttes på en bred vifte af systemer, inkl. verdens måske mest udbredte *nix, Mac OS X.

  • 15
  • 3
Mikkel Kirkgaard Nielsen

Artiklen bærer tydeligt præg af at være oversættelsesarbejde af en ikke særlig oplyst artikel på Computerworld, og der er flere ting jeg gerne vil pointere;

  1. 'less' har intet med Linux at gøre. Linux er en OS-kerne, hvor less er en applikation der kører i usermode på POSIX-kompatible systemer, herunder bl.a. mange Linux-baserede desktop distributioner som typisk anvender værktøjer fra GNU-projektet (GNU/Linux), men også andre POSIX-systemer som *BSD, OSX mm.
    De-facto implementationen af less er GNU less (http://www.gnu.org/software/less/), som vedligeholdes af Mark Nudelmann, og kan findes her; www.greenwoodsoftware.com/less/

  2. De korrekte miljø(environment)-variable der styrer indput-præprocessering er LESSOPEN og LESSCLOSE (med versaler, POSIX er vasalfølsom!), og det er kun LESSOPEN der er nødvendig at redefinere da LESSCLOSE kun anvendes i fald førstnævnte er i brug. Dette kan f.eks. gøres permanent ved at tilføje 'export LESSOPEN=' i ~/.bashrc.

  3. I nyere udgaver af less kan man slå brugen af LESSOPEN helt fra med -L eller --no-lessopen på kommandolinien, dette virker på Ubuntu 14.10, som anvender less 458 (24 Apr 2013) (http://packages.ubuntu.com/utopic/less). Dette kan f.eks. gøres permanent ved at tilføje 'alias less="less -L"' i ~/.bashrc.

  4. Sårbarheden ligger mere i det der foregår i kommandoen der defineres af LESSOPEN, end i selve less. Hvis man kun anvender programmer man stoler på i LESSOPEN (som under Debian/Ubuntu kalder shell-scriptet lesspipe), så er der ingen fare på færde;
    miki@miki:~$ lsb_release -d
    Description: Ubuntu 14.10
    miki@miki:~$ echo $LESSOPEN
    | /usr/bin/lesspipe %s

Det kan selvfølgelig altid diskuteres hvad standardopførslen for less skal være, personligt har jeg aldrig forventet at less kunne andet end at vise ascii-tekst, så jeg vil ikke mangle denne udvidede fortolkningsfunktionalitet. Jeg bygger typisk selv kommandolinien op til det program jeg ønsker at anvende i en given situation (eks. zcat /var/log/syslog.2.gz |less).

Mikkel

  • 24
  • 1
Lars Lundin
  • 8
  • 1
Mike Mikjær Blogger

Version2 kunne spare mange penge ved at fyre journalist stablen, ingen af artiklerne (og jeg mener ingen) har nogen anvendelighed og man ender altid med at læse kilden for at forstå indholdet korrekt, eller trække lidt på skuldrene fordi man ved bedre selv.

Et koncept som newz.dk der blot linker til nyhederne og debattere dem på Dansk ville fungere ligeså godt, jeg kommer på version2 for overskrifterne, debatterne og så er et par af jeres bloggere også værd at følge.

  • 6
  • 12
Kim Jensen

Det er stadigvæk ikke Linux der er sårbar. Det er POSIX.


Der står altså mig bekendt ikke noget i POSIX standarden om at det skal være muligt at eksikvere indlagt kode igennem less (eller f.eks. bash), og alle sådanne kreative muligheder skal selvfølgelig udryddes helt og aldeles.

Om hvorvidt Linux er sårbar afhænger nok meget af hvor mange services man tillader at køre på sit system, og om man tror på automatiske opdateringer (da de muligvis kan hackes af krypto eksperter eller af dem der har nøglerne), og om man har styr på at programmere sin firewall (f.eks. hardcore med iptables), samt om er så dum f.eks. at køre en GUI maskine som server mv.

Og så hjælper det også meget at man programmerer alarmer i sit system, så man får besked om system ændringer, og automaisk optager alt hvad der sker på systemet på et eksternt parallelt system (f.eks. vha. af spejlede diske som kan overvåges fra en anden computer). Og så skal man selvfølgelig sniffe alt trafik på sit netværk, så man kan studere hændelserne hvis alarmen går af. osv. Ekstra værktøjer som f.eks. Yubikey kan også være gode især hvis man ikke er Rainman og selv kan huske lange sikre password sekvenser. Til fjernadministration er det nok bedst at bygge sit eget hemmelige system som kun en selv kender (og som f.eks. bruger lange lister af symmetriske engangs passwords). Det samme gælder for andre *nix systemer (selv vil jeg anbefale OpenBSD). Sikkerhed på Microsoft kan man godt glemme, da det svarer til at tro nisser.

  • 2
  • 2
Kim Jensen

Problemet eksisterer dog for alle POSIX-compliant systemer og ikke kun for Linux.

Det er også de samme tiltag der skal til for alle POSIX-compliant systemer for at undgå problemerne i at opstå.

Nej, det mener jeg bestemt ikke. POSIX er en standard for hvilken funktionalitet et POSIX-compliant system skal stille til rådighed. F.eks. hvilke parametre et API skal have. Der står intet om hvordan man skal implementere (altså kode) et system til at overholde standarden, men kun hvad systemet som minimum skal kunne og standard for komminakation, bla. således at der er nemt f.eks. at portere programmer mv.

Da Linus Torvalds startede med at programmere Linux, da fik han et kopi af POSIX standarden, og sammen med andre skrev han/de selv alt koden fra bunden (der er ingen kopikode i Linux ifølge Linus Thorvald).

Der står intet i POSIX standarden om at hvis man f.eks. åbner en fil med less at det så skal være muligt at kode i filen skal eksikveres på systemet. Der står heller ikke noget om at det i Bash skal være muligt at skrive scripts der kan eksikvere kode som ikke er en del af script sproget (men kun et det skal være muligt at kalde andre programmer i systemet). Eller f.eks. som med Shellshock at eksikvere shell kommandoer som man ikke burde have rettigheder til. Hvis disse fejl havde stået i POSIX standarden, så var de blevet fundet for længe siden.

POSIX standarden kan læses her: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

  • 3
  • 1
Kim Jensen

Der står heller ikke noget om at det i Bash

bash er overhovedet ikke en del af POSIX-standarden.

Der er korrekt. Jeg har heller ikke skrevet at bash var en del af POSIX standarden, men da en anden i tråden nævnte bash prøvede jeg at forklare at de fejl man har fundet i bash ikke er defineret i POSIX standarden (da en anden på tråden påstår at der POSIX standarden der er problemet). Bash kan dog køre i en POSIX-complaint mode, og bruges ofte på systemer der overholder POSIX standarden. Bash kan dog siges at være en 'dialekt' af POSIX shell sproget sh.

  • 0
  • 1
Troels Henriksen

Hvis jeg compiler less til NetBSD, så vil problemet også findes i NetBSD. Ergo er det ikke en Linux-sårbarhed.

Det er i så fald heller ikke en less-sårbarhed. Problemet er at less starter andre (kendte via en miljøvariabel) programmer, der potentielt kan have sårbarheder, selvom less isoleret set klarer sig fint. Fejlen skyldes således dårligt opsatte konfigurationer af less, kan man sige, og disse er åbenbart alle Linux-baserede.

  • 2
  • 0
Kim Jensen

Jeg siger ikke at det er POSIX-standarden der er problemet. Jeg siger at problemet eksisterer for alle POSIX-compliant systemer. Hvis jeg compiler less til NetBSD, så vil problemet også findes i NetBSD. Ergo er det ikke en Linux-sårbarhed.

Altså, du starter med at sige "Det er stadigvæk ikke Linux der er sårbar. Det er POSIX.", og så siger jeg nej det passer ikke at det er POSIX der er sårbar, da POSIX bare er en implementations uafhængig standard. Der er intet galt med POSIX, og at der er er fundet nogle fejl på nogle af de systemer der helt eller delvis overholder POSIX standarden, gør ikke at der er noget galt med POSIX, men dog at der er noget galt med nogle af de implementationer som helt eller delvis overholder standarden.

  • 0
  • 0
Daniel Udsen

Men de understøtter programmerne. Der skal minimalt arbejde til for at have less og bash på de systemer der ikke leveres med dem som standard.

Hvis du har plads og tør bruge 3je parts repositories. Embedded linux kommer meget sjældent med bash og gnu fileutils af pladshensyn men bruger ash og busybox.

HPUX har ikke officiel understøttelse for gnu utils og det er typisk en verden hvor man ikke bare lige downloader fra et uoffociele repositories.

Jeg er enig i at det forkert at fremhæve linux og ikke OSX som udsat eftersom alle de her fejl også findes i OSX og apple har et værre "track record" når det kommer til rettelse end Mainline linux.

et eller andet sted mellem 80-90% af alle linux systemer er faktisk imune over for de her linux fejl fordi de netop kommer med ash og busybox af pladshensyn men det er også de 80-90% af linux markedet hvis brugere ikke ved de faktisk bruger en linux kerne.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Jobfinder Logo
Job fra Jobfinder

Call to action

At benytte Linux' 'less'-kommando til at gennemse indholdet af en fil, som man har downloaded fra nettet, kan være en farlig operation. Det skriver Computerworld.com. En sikkerhedsefterforsker har nemlig fundet ud af, at man, selvom man kun gennemser filen, stadig kan komme til at starte en 'Remote
code execution'. Ved første øjekast ligner det en harmløs kommando, som viser en fils indhold i et terminalvindue og giver brugeren lov til at navigere gennem den. Less giver ikke lov til at ændre noget, hvilket man har andre programmer til. I stedet har less den fordel, at det kan vise filerne, uden at man er nødt til at bruge computerkraft på at loade hele filen, hvilket især er brugbart m...