Alvorlig hull i Debian

[int20h]

Samtlige Debian-baserte Linux-distribusjoner inneholder et seriøst sikkerhetshull i SSH.

 

Les mer

[Tordenflesk]

[t_k]

Ble oppdatert i går.

[CAT0]

Hva med å nevne at den også ble patchet sånn ca. samtidig med at det ble oppdaget? Eller kjører man sparebluss på jounalistikken?

[t_k]

Sjokk nyheter selger. Ubuntu ståååår viiiiid åpeeen!

[HKS]

Er ganske hard for mange å se at det også dukker opp alvorlige sikkerhetshull i Linux-baserte systemer.

 

Selv om dette er patchet nå så er det fremdeles mange systemer som enda ikke er oppdatert. Dette er ett meget stygt sikkerhetshull.

[Rabbid]

Er ihvertfall positivt at det ble fikset såpass raskt da (i følge diverse blogger ihvertfall)

Endret 16. mai 2008 av Rabbid

[rocknrolf77]

Det står også i ssh config fila at man burde bytte fra port 22 til en annen, da dette ikke er en trygg port. Gjelder dette bare port 22 da som det står i artikkelen? Tror de fleste oppegående it admins bytter denne porten med en gang før de startet opp ssh serveren.

[Gjest Slettet+6132]

Ethvert populært og mye brukt OS *vil* bli utsatt for angrep.

 

Lurer på hvor mye det har å si at *nix er "Open SOurce" slik at evt hackere kan lese koden og evt letter finne måter å kode "hack" på?

[Ördög]

Dette gir nok "vann på mølla" for alle Mac og Win fanboys/girls. Venter i spenning på kommentarene.

 

MEN, det er jo retta. Så burde ikke være noe problem.

 

 

@Tordenflesk: morsomt bilde

[Rabbid]

Ethvert populært og mye brukt OS *vil* bli utsatt for angrep.

 

Lurer på hvor mye det har å si at *nix er "Open SOurce" slik at evt hackere kan lese koden og evt letter finne måter å kode "hack" på?

Men hvis hackerne kan lese koden og finne hullet kan jo alle andre gjøre det og, feilen ligger ikkke skjult og uoppdaget lenge. Hackere kommer seg også inn uansett, trenger ikke kildekoden til å gjøre det. Endret 16. mai 2008 av Rabbid

[andylove]

Det jeg ikke forstår er at dette sikkerhetshullet kommer fra en "second" løsning for SSH (eller var det SSL?). I kjernen er det allerede en løsning, som ikke har noe sikkerhetshull. Litt merkelig vurdering ja.

 

Må få si meg enig i at denne "nyheten" ikke inneholder alle fakta. Hullet ble oppdaget for et par-tre dager siden og har blitt tettet igjen.

 

Hilsen Windows-mann (så er det ingen tvil om at jeg ikke tar dette så veldig tungt...).

[DevilsDecoy]

Det står også i ssh config fila at man burde bytte fra port 22 til en annen, da dette ikke er en trygg port. Gjelder dette bare port 22 da som det står i artikkelen? Tror de fleste oppegående it admins bytter denne porten med en gang før de startet opp ssh serveren.

Bytte port kan hjelpe, men bare fordi færre prøver andre porter, ikke fordi det faktisk fikser noe (Security through obscurity)...

 

Artikkelen nevner også 'feil' brute-force, det er ikke passord, men nøkler som kan gjettes. Mer spesifikt er det nøkler generert med en versjon med denne feilen, som forøvrig har vært tilstede siden 2006-09-17/0.9.8c-1. Kan også nevnes at det ikke holder å oppdatere SSH, men at man må regenerere nøklene sine.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

 

http://it.slashdot.org/article.pl?sid=08/0...12&from=rss

http://article.gmane.org/gmane.linux.debia...y.announce/1614

[oyvindne]

Er ganske hard for mange å se at det også dukker opp alvorlige sikkerhetshull i Linux-baserte systemer.

 

Selv om dette er patchet nå så er det fremdeles mange systemer som enda ikke er oppdatert. Dette er ett meget stygt sikkerhetshull.

 

Selvfølgelig vil det også være sikkerhetshull på linux maskiner... Som windows og OS X er en Linux distro en massiv samling av kode (bare kjernen er vel 5-6 millioner linjer), og det er praktisk umulig at det ikke finnes feil.

 

Så alle OS vil ha feil, så den viktige forskjellen er hvor fort disse feilene blir rettet opp. Etter min erfaring har de tre OS'ene en responstid omtrent som dette:

 

GNU/Linux: Feil blir rettet på et par dager

Windows: Feil blir rettet på et par uker

OS X: Feil blir rettet på et par måneder

 

Så... velg selv!

 

Lurer på hvor mye det har å si at *nix er "Open SOurce" slik at evt hackere kan lese koden og evt letter finne måter å kode "hack" på?

 

Open source er selvsagt en "mixed blessing". Det er en ulempe at black hat hackere har tilgang på koden, siden det lettere kan finne exploits (selv om jeg tror de oftere jobber med prøve og feilemetoden). Men det er derimot en stor fordel at alle kan lese koden, og finne feil. Alle som har programmert vet at det er vanskelig å se egne feil, og at jo flere som titter på koden, jo flere feil kan man avsløre.

[enixitan]

Er ikkje fokuset litt feil her? Det er ikkje i SSH feilen er, men i Debians "fiksa" utgåve av OpenSSL, som bl.a. SSH (på Debian) brukar til kryptering. Feilen gjeld all programvare som brukar OpenSSL på Debian (før det vart fiksa), og alle nøklar som er generert med den aktuelle versjonen er usikre.

 

Ein kan vel ikkje bare brute-force-angripe port 22, ein må framleis ha eit brukarnamn, og gjette på den private nøkkelen. Dersom brukaren ikkje brukar nøklar, men passord, må ein ha samla opp datapakker frå ei SSH-økt, dekryptere desse, og lese det. Ein kan gjere tilsvarande med annan OpenSSL-kryptert trafikk (igjen, dersom nøklane er laga med den sårbare versjonen frå Debian).

 

Slik har i alle fall eg forstått det.

[Brukerkonto inaktiv]

Vel,

 

Nå er vel dette et av de mer alvorlige sikkerhetsbristene på lang tid, så det er ingen grunn til å være eplekjekk.

 

Det ER positivt at patch og info ble lagt ut raskt og med en klar oppfordring til å oppdatere, sjekke alt som er generert med koden OG å foreta avsetninger i BUDSJETTENE. For dette koster penger!

 

Verdt å merke seg er også at åpenheten kommer til sin fulle rett:

• Man vet HVA som skjedde
  
• NÅR det skjedde
  
• HVORDAN det skjedde
  
• HVORFOR det skjedde
  
• HVEM som utførte endringer
  
• Hvor ANSVARET ligger
  
• HELE DIALOGEN rundt endringen er tilgjengelig
  
• KONSEKVENSEN er ikke lagt skjul på
  

Selv om en patch kom ut raskt er det all grunn til å regne med at det er svært svært mange som er berørt uavhengig av operativsystem. Så lenge nøkler har blitt generert på en berørt server. Det er ikke bare å patche og tro at problemet derved er borte. Brukere må gjennomgå alt som er beskyttet på denne måten og dersom noen har sikret seg informasjon som er beskyttet på denne måten kan man gå inn å knekke beskyttelsen av denne informasjonen.

 

Det vil si at dersom jeg sitter på 1 mill av andres sensitive "dokumenter" som er "beskyttet" ved bruk av dette kan jeg gå inn i ettertid. Her er det mange som står med buksa på knærne.

 

Det er kanskje viktig å få med seg at dette ikke er et problem med Linux - som er kernelen, men med en rekke distroer basert på Debian. Det er heller ikke et OpenSSL-problem - OpenSSL-prosjektet er et offer i denne saken som deg og meg.

 

Det blir litt som om man kjøper en bil. Dersom en mekaniker hos en bruktbilforhandler avmonterer bremsene og bilkjøperen gir bremsprodusenten skylden når bilene krasher.

 

Ingen tvil om at dette er meget alvorlig og at Debian har gjort en gigantisk brøler, men det kan også være greit å huske på at mange som driver servere oppdaterer ting som OpenSSL direkte fra kilden og ikke via en Distro. Disse vil derfor ikke være berørt. Slike saker er også et godt eksempel på hvorfor man bruker forskjellige distroer for "enterprise" som f.eks RHEL vs Fedora og Novell desktop Vs OpenSuse. I dette tilfellet blir en "konservativ" distro som Debian berørt på lik linje med mer "Flimsy" Ubuntu, så det finnes ikke absolutte sannheter.

 

Det er en oppside ved dette:

• Det vil komme en reell debatt om hvor man skal vedlikeholde pakker
  
• Distroene vil kanskje bli flinkere til å sende bugrapporter (og bugfixer) tibake til de som utvikler programvaren istedet for å fikle selv.
  
• Man kan få en avklaring og tydeliggjøring av rollene til Distroene og programvaren.
  
• Distroene kan bli mer konservativ i hva de slipper inn i distroene.
  

[t_k]

Fint at folk også lærer om porter, og forhåpentligvis ikke lar disse stå åpen helt ukritisk.

 

Folk burde også begynne å tenke på og blokke ut IP adresser med feks MoBlock.

 

https://help.ubuntu.com/community/MoBlock

[Bolson]

Regenering av nøkler ble jeg faktisk bedt om når jeg kjørte oppdatering på Ubuntu med denne feilfiksen.

 

@[GDI]Raptor: Sikkerhetshull i tredjeparts-programmer (noe OpenSSH er) på Linux er langt fra uvanlig, her i dette tilfellet ikke hos OpenSSH, men hos Debian. Problemet her er jo primært at man kan "bruteforce" seg inn via ssh, noe som er særdeles uheldig, samt at mange andre tjenester bygger på å bruke OpenSSH som sikkerhet på Ubuntu eller Debian.

 

Og jaggu skal jeg si de prøvde seg når hullet ble kjent. Aldri opplevd slik trafikk jeg. Men så langt jeg kan se pr dato, ikke en eneste kom inn. Men må nok overvåke noen dager til. Nå bruker jeg ikke OpenSSH som sikkerhet på andre tjenester.

 

Men det å sikre serveren bare med nøkler i forhold til ssh er uansett for svakt. Litt mer sikkerhet bør man legge inn, slik som avgrense brukernavn, kun innlogging fra gitte ip-adresser mer mer.

 

Ellers en meget bra post fra Omaha

Endret 16. mai 2008 av Bolson

[Simen1]

Lurer på hvor mye det har å si at *nix er "Open SOurce" slik at evt hackere kan lese koden og evt letter finne måter å kode "hack" på?

Security through obscurity vs. Security by design

 

Kort forklart: Lukket kildekode er ikke noen garanti for at programvaren er fri for hull. Det gjør det bare litt vanskeligere å finne de og mange færre til å rette opp hullene. Åpen kildekode er derimot lettere å oppdage feil i og gir langt flere muligheten til å rette feil. Åpen kildekode gir altså mer feilsikre design. 1 måned betaperiode gir mer og bedre feilfjerning når koden er åpen enn når den er lukket fordi det er flere øyne til å følge med, teste og rette opp ting.

 

På lengre sikt vil åpen kildekode føre til grunnleggende sikrere systemer og raskere evolusjon av programvaren. Det er også en trend man lett kan kjenne igjen i konkurransen mellom Linux og Windows de siste 10-15 årene.

 

PS. Er det noen som vet hvor mange timer det gikk fra oppdagelsen til det var tettet?

[Peter]

Mange som nevner porter og andre rare greier her. Feilen lå i generereringen av nøkler (noe mange ikke engang bruker), som førte til at nøkler ikke var så tilfeldige som de skal være, og større nettsteder hvor brukere laster opp nøklene sine (f.eks github) så at det var mange kollisjoner, noe som potensielt er veldig farlig da nøklene burde være unike.

 

Mange som skryter av at feilen ble raskt rettet, men det hjelper ikke med mindre man faktisk oppdaterer. Det samme problemet har man i os x og windows også, at folk ikke vet hvor oppdateringsknappen sitter eller hvordan den brukes.