☰

» »

Glibc bug

Glibc bug

denial ::

Podrobnosti: KLIK
Confirmed on CentOS 5.5. Ubuntu 10.10 protected by hard/sym link restrictions
SELECT finger FROM hand WHERE id=3;

denial ::

Linux RDS protocol local EoP: KLIK
Patch: KLIK
SELECT finger FROM hand WHERE id=3;

fiction ::

Ok najprej to, če bo koga zanimala razlika med DT_RPATH in DT_RUNPATH. DT_RPATH je najbolj pomemben in se najprej išče library v tem direktoriju. LD_LIBRARY_PATH tega ne overrida, DT_RUNPATH pa. Če imaš v binaryu zapečen DT_RUNPATH se DT_RPATH ignorira. In kot je rekel Tavis, karkoli relativnega tam notri je bad za suid/sgid programe (posebej je zanimivo tisto, da "" pomeni v bistvu ".", kar je precej pogost problem zaradi napak v build skriptah). $ORIGIN je pa direktorij v katerem je executable. Ampak tudi to ni v redu, ker lahko narediš hardlink na executable v delu direktorijske strukture, ki jo kontroliraš.

V luči tistih binary planting napadov na Windows OS:

With both implicit and explicit linking, Windows first searches for "known DLLs", such as Kernel32.dll and User32.dll. Windows then searches for the DLLs in the following sequence:
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
Točka 1 je v bistvu impliciten rpath=$ORIGIN, right? Si predstavljam, da bi vse skupaj nekako portal v privilege escalation bug na Winse. Samo hja, zgleda da hardlinke lahko delaš, setuid koncepta pa nimaš ravno.

Reliable Datagram Sockets (RDS) is a high-performance, low-latency reliable connectionless protocol for delivering datagrams. It is developed by Oracle Corporation.
It was included in the Linux kernel 2.6.30 which was released on 9th of June, 2009. The code was contributed by the OpenFabrics Alliance (OFA).
Uf, nikoli prej nisem slišal za RDS. Je pa zgleda vse skupaj uporabno, če hočeš pisati po kernel memoryu ;)

Zgodovina sprememb…

  • spremenil: fiction ()

denial ::

RDS bug sem reproduciral v Ubuntu 10.10. It worked like a cham. Kar se glibc buga tiče pa lahko le ugibam(o) koliko časa je bilo to znano v privatnih krogih: KLIK
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

noraguta ::

sej dinamično ladanje knjižnic na splošno ni obvladljivo. mogoče z podpisi ter nošnjo odgovornosti. sicer pa plugin je vedno lohk spravu aplikacijo na noge. tuki za ker sistem gre niti ni problem. sej delno zarad tega se grejo kanale ter podobne komunikacije med procesi kjer ukinjajo dll v klasičnem pomenu besede.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • spremenilo: noraguta ()

fiction ::

denial je izjavil:

Patch: KLIK
Pod patch sem pričakoval output od programa diff med staro in novo verzijo.

denial je izjavil:

RDS bug sem reproduciral v Ubuntu 10.10. It worked like a cham. Kar se glibc buga tiče pa lahko le ugibam(o) koliko časa je bilo to znano v privatnih krogih: KLIK
Glibc 2.4 je bil izdan 6.3.2006, torej po pesimistični oceni je bilo vse skupaj znano blackhatom od takrat. Bug je sigurno nastal takrat, ker gre za copy-paste $ORIGIN funkcionalnosti pri uvedbi LD_AUDIT (po nesreči). To valda niso prej dobro naredili in potem breakali.

Naslednja nevarnost je LD_HWCAP_MASK. Kaj ta spremenljivka okolja, ki se za suid/sgid programe ne scleara, točno počne?

fiction ::

denial je izjavil:

RDS bug sem reproduciral v Ubuntu 10.10.
O čemer niti ni bilo dvoma, saj je zadeva 100 % reliable. S pomočjo kernel simbolov točno veš na katerem naslovu je kaj. In ker direktno pišeš te tudi nič ne more zaščiti (niti ne gre za overflow ali kaj podobnega, pa tudi sicer se to zgodi v kernel memoryu, kjer ni nekih blaznih zaščit, saj ponavadi nimaš dostopa tja).

Tista koda za resolvanje simbolov je direktno copy-paste od spenderja in je kar precej portable, edino če tisto ne bi delovalo, exploit ne bi dobro delal, kar pa še ne pomeni, da si safe.

V jedru ima vsak tip socketa nek "ops" kjer so pointerji na funkcije, ki implementirajo določen klic (bind, listen, ioctl itd). Napad izgleda potem tako, da na sock_ops + (9 * dolžina naslova) ali sock_ops[9] napišeš pointer na tvojo kodo. To je zgleda v originalu kazalec na funkcijo, ki implementira ioctl() klic. To enostavno spremeniš, da kaže to na tvojo funkcijo (getroot) in pokličeš ioctl() pa je.

Zanimiv je potem način kaj tvoja koda v jedrnem načinu naredi, da pridobiš administratorske pravice. Na podlagi znanih exploitov sem identificiral dva načina. Star (bolj hekerski) način je, da ugotoviš kje je task_struct struktura.

asm volatile ("movq %%rsp,%0; " : "=r" (sp));
task_struct1 = sp & ~(8192 - 1);
unsigned int *task_struct;
task_struct = (unsigned int *)task_struct1;
oz. en kos pomnilnika dovolj blizu
asm volatile ("movq %%gs:(0x0), %0" : "=r"(gs));
in potem tam iščeš za tvojim UID in GID-om ter ju probaš spremenit na 0 (root).

Novejši način je pa klic commit_creds(prepare_kernel_cred(0)); Ti dve funkciji (ki sta tudi na dobro znanih naslovih pridobljenih iz kernel simbolov) sami spremenita privilegije trenutnega procesa in ni treba čarati. Paziti je treba samo na način klicov __attribute__((regparm(3))), tako da se parametri prenašajo preko registrov EAX, EDX in ECX.

Potem tvoj proces teče kot root in je vse kul. Lahko poženeš shell ali karkoli hočeš.

denial ::

Pod patch sem pričakoval output od programa diff med staro in novo verzijo.

Enjoy :D

O čemer niti ni bilo dvoma, saj je zadeva 100 % reliable.

I always try to reproduce bugs. In to na najmanj dveh distribucijah (Red Hat/Debian based). Stara navada pač...
SELECT finger FROM hand WHERE id=3;

fiction ::

noraguta je izjavil:

sej dinamično ladanje knjižnic na splošno ni obvladljivo. mogoče z podpisi ter nošnjo odgovornosti
Tukaj ni fora to, da bi bil en vulnerable plugin, ki bi povzročal težave. Takrat je res vprašanje, kdo je odgovoren za probleme (avtor programa, avtor plugina), dobiš lahko backdoorane plugine itd. V opisanem primeru je program, ki je tekel z višjimi privilegiji, pod določenimi pogoji vzel knjižnice, ki mu jih je dal nepriviligiran uporabnik. Napaka je torej 100 % na strani programa in poleg tega je ta tudi enostavno odpravljiva. Oz. OK tukaj je šlo za loader, ampak pustimo to.

noraguta je izjavil:

sej delno zarad tega se grejo kanale ter podobne komunikacije med procesi kjer ukinjajo dll v klasičnem pomenu besede
Vprašanje je samo ali "najameš nekoga tako, da mu rečeš, naredi to in potem od njega vzameš rezultat" (overhead je komunikacija) ali pa "ga povabiš da dela k sebi v hišo (proces)". Kakor hitro je tam not ti lahko teoretično ukrade kar hoče (izvede poljubno kodo kot ti), je pa zato, če je pošten, tebi veliko lažje.

fiction ::

denial je izjavil:

O čemer niti ni bilo dvoma, saj je zadeva 100 % reliable.

I always try to reproduce bugs. In to na najmanj dveh distribucijah (Red Hat/Debian based). Stara navada pač...
Script kiddie! :) Bolje je prej pogledati, kaj zadeva sploh dela...

denial je izjavil:

Pod patch sem pričakoval output od programa diff med staro in novo verzijo.

Enjoy :D
Hvala. Sej bi tudi sam našel. Khm _atomic in _inatomic so vrgli ven in direktno kličejo navadne funkcije ala copy_to_user(). Ta je pa afaik pred kratkim dobila check, če je destination res user-space.

Zlobni heker bi ponavadi poiskal kje se __copy_to_user_inatomic še uporablja in če je še kje drugje problem.

denial ::

Tista koda za resolvanje simbolov je direktno copy-paste od spenderja...

/proc info-leaki so precej pereč problem. Le komu koristijo world readable kernel simboli (/proc/kallsyms)?

Script kiddie! :)

Yea, and I'm proud!! :P
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

noraguta ::

fiction je izjavil:

noraguta je izjavil:

sej dinamično ladanje knjižnic na splošno ni obvladljivo. mogoče z podpisi ter nošnjo odgovornosti
Tukaj ni fora to, da bi bil en vulnerable plugin, ki bi povzročal težave. Takrat je res vprašanje, kdo je odgovoren za probleme (avtor programa, avtor plugina), dobiš lahko backdoorane plugine itd. V opisanem primeru je program, ki je tekel z višjimi privilegiji, pod določenimi pogoji vzel knjižnice, ki mu jih je dal nepriviligiran uporabnik. Napaka je torej 100 % na strani programa in poleg tega je ta tudi enostavno odpravljiva. Oz. OK tukaj je šlo za loader, ampak pustimo to.

noraguta je izjavil:

sej delno zarad tega se grejo kanale ter podobne komunikacije med procesi kjer ukinjajo dll v klasičnem pomenu besede
Vprašanje je samo ali "najameš nekoga tako, da mu rečeš, naredi to in potem od njega vzameš rezultat" (overhead je komunikacija) ali pa "ga povabiš da dela k sebi v hišo (proces)". Kakor hitro je tam not ti lahko teoretično ukrade kar hoče (izvede poljubno kodo kot ti), je pa zato, če je pošten, tebi veliko lažje.

ja sam temu bi človk reku kar frustrated by design kar se tiče dinamičnega povezovanja.
Pust' ot pobyedy k pobyedye vyedyot!

denial ::

Kaj o bugih pravi Heise Sec: RDS in Glibc. Easy reading :D
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

fiction ::

denial je izjavil:

Tista koda za resolvanje simbolov je direktno copy-paste od spenderja...
/proc info-leaki so precej pereč problem. Le komu koristijo world readable kernel simboli (/proc/kallsyms)?

No ja, sej kernel simbole bi lahko dobil tudi na drug način. Če ne drugega direktno iz vmlinuz. Ok, lahko zbuildaš in stripaš vse skupaj, samo potem, ko dobiš npr. kernel panic, tega ne moreš lepo reportati in tudi sam nimaš pojma kaj je bilo. Me pa zanima, ali lahko narediš, da vmlinuz ni world-readable. Sej načeloma bootloader ničesar ne ve o permissionih filesistema...

Sicer je pa ta workaround itak bolj security-through-obscurity. Brez simbolov, bi lahko naredil isto kot prej, vprašanje je samo kaj prepisati kot sprožilec. Jaz bi v tem primeru vzel kar syscall table. Takole bi v primeru SYSENTER dobil naslov v pomnilniku jedra. Potem bi nekaj tam prepisal (v tem delu si pomoje lahko privoščiš malo sprayanja okrog) in naslednjič, ko bi npr. rekel open() oz. poklical kakšen sistemski klic bi se izvedla moja koda v kontekstu jedra. Ta bi potem po bruteforce varianti spremenila UID na 0.

denial je izjavil:

RDS in Glibc. Easy reading :D
Tisto o glibc je bullshit.
The new problem is rooted in the way in which the loader expands the $ORIGINS variable submitted by the application
Ni res. Nov problem je v tem, da se pri LD_AUDIT $ORIGIN (ne $ORIGINS) sploh expanda, kar je posledica copy-pasta. In $ORIGIN ni "submitted by the application", to je
pač samo kje se aplikacija nahaja.

While Tavis Ormandy, who discovered the hole, said that the ELF specification recommends that the loader is to ignore $ORIGIN with SUID and SGID binaries, it appears that the glibc developers haven't implemented this recommendation.
Zato, ker glibc developerji ne držijo programerjev za roko. Če uporabljaš $ORIGIN v rpath v setuid programu si sam kriv. Ampak tukaj to ni problem. Problem je uporaba v LD_AUDIT (v vsakem primeru).

Zgodovina sprememb…

  • spremenil: fiction ()

denial ::

Ni res. Nov problem je v tem, da se pri LD_AUDIT $ORIGIN (ne $ORIGINS) sploh expanda

Očitno so spregledali naslednjo vrstico v Tavisovem exploitu:
$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
:)

Zakaj je vredno vložiti nekaj truda v reproduckcijo bugov:
$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!


Problematični del kode v Ubuntu 10.04 LTS uporablja assert() macro. Ubuntu 10.10 pa ima implementirane hard link restrikcije. Oh, the joys of Linux flavours. Kjer se hitro zgodi da prideš bez kur** na svatbu :D

Glede /proc info-leakov... chmod 440 /proc/kallsyms potem pa poskusi reproducirati enega od zadnjih kernel EoP bugov. Seriously, le zakaj 440 ni default?

Res je, obstajajo drugi načini kako doseči enak rezultat. V najbolj kmečkem primeru lahko exploit vsebuje hard-coded naslove kernel simbolov. Vendar ne vidim razloga zakaj "nepridipravom" olajšati delo.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

fiction ::

denial je izjavil:

Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed! Problematični del kode v Ubuntu 10.04 LTS uporablja assert() macro.
Ja, to je že Tavis omenil. Če skompilaš glibc z -DNDEBUG bo vseeno delalo ;) Boljše vprašanje pa je kako priti okrog tega v default buildu. Drugače je dodan check v macroju DL_DST_REQUIRED v dl-dst.h (tisto kar se izpiše je malo misleading, ravno zaradi tega, ker macro že preprocesor zamenja z dejansko kodo)

denial je izjavil:

Ubuntu 10.10 pa ima implementirane hard link restrikcije.
Ah, to je spet nek beden workaround v stilu noži so nevarni, bomo raje vsem dali plastične nože namesto železnih. Če si paranoičen, imaš na voljo nosuid mount opcijo za particije, kamor lahko piše user. Tam pač ne more biti suid datotek. Linke naj pa ljudje delajo, kakor jih je volja.

denial je izjavil:

Glede /proc info-leakov... chmod 440 /proc/kallsyms potem pa poskusi reproducirati enega od zadnjih kernel EoP bugov. Seriously, le zakaj 440 ni default?
Zadeva je na voljo najmanj še na dveh drugih mestih (System.map, vmlinuz). Poleg tega pa to, da ni simbolov kot prvo "omejuje" tebe, ne samo napadalca. Če karikiram, lahko bi tudi rekel zakaj zaboga je na voljo Linux source, tako napadalci samo lažje najdejo buge... :) Sicer sem pa že opisal način, kako izkoristit bug brez simbolov. Verjamem, da je sigurno kakšna bolj elegantna verzija exploita "v divjini".

denial je izjavil:

Res je, obstajajo drugi načini kako doseči enak rezultat. V najbolj kmečkem primeru lahko exploit vsebuje hard-coded naslove kernel simbolov. Vendar ne vidim razloga zakaj "nepridipravom" olajšati delo.
Sej razumem point. Ampak skrivati naslove jedra se mi zdi malo čudno in ne preveč izvedljivo. Za kernel, ni nekega ASLR, kar naredi vse skupaj predvidljivo, tudi če zapreš vse "leake". Se pravi v originalu ima napadalec 100 %, da owna mašino, po novem pa recimo 75 %, da owna mašino in 25 %, da jo sesuje (pri čemer ima po resetu mogoče še kakšen poskus). Ni ravno velik gain.

fiction ::

fiction je izjavil:

Zlobni heker bi ponavadi poiskal kje se __copy_to_user_inatomic še uporablja in če je še kje drugje problem.
Haha: CVE-2010-2962: Linux kernel i915 GEM Memory Corruption. Zdaj vem, kako je Dan Rosenberg našel RDS bug. Na podlagi prej odkritega i915 buga, ki je na podoben način uporabljal copy_to_user_inatomic() s ciljnim naslovom od uporabnika. Search for related stuff in je dobil bug, ki je še bolj enostavno exploitable.

Zgodovina sprememb…

  • spremenil: fiction ()

denial ::

Tavis' addendum to Glibc issue: KLIK

This is a low impact issue that is only of interest to security
professionals and system administrators, end users do not need to be
concerned.

It is possible to exploit this confusion to execute arbitrary code as root.

Zmagovalna izjava... :D
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

fiction ::

Evo pa je problem z nedelovanjem na novejših verzijah Ubuntu Linuxa rešen. :)
Ta LD_AUDIT je bil zgleda res dobro stestiran. ;)

Za suid / sgid program lahko LD_PRELOAD-aš lib iz standardnega library search patha (/lib, /usr/lib) samo če je tudi library suid. Ker knjižnice nikoli ne izvedeš direktno, v bistvu tisti flag nima smisla. Zanimivo je pa to, da tako označiš, da je library "safe". Tega se prej nisem zavedal (tako kot LD_AUDIT). Prav tako ne tega, da dejansko obstajajo legitimate knjižnice, ki delajo nevarne stvari v konstruktorju. Sem mislil, da je vse kar je v sistemskih poteh za knjižnice OK in nima veze, če se to naloži.

LD_AUDIT tako v bistvu naloada drugo knjižnico, ki je prisotna na sistemu. V knjižnici išče sicer neke svoje simbole, ampak prej mora v vsakem primeru poklicati konstruktor, tako da nič ne škodi tudi če tistega kasneje ne najde. Problematična koda, ki je tekla kot root, se je že izvedla.

denial je izjavil:

This is a low impact issue that is only of interest to security
professionals and system administrators, end users do not need to be
concerned.

It is possible to exploit this confusion to execute arbitrary code as root.

Zmagovalna izjava... :D
Hehe. To je pomoje letelo na to, da vsak, ko odkrije nek bug, zganja hype kot da bo zaradi tega konec sveta, ne glede na to, da je stvar exploitable mogoče samo v neki XYZ konfiguraciji ali pa z izdatno mero social engineeringa.

denial ::

Me pa zanima, ali lahko narediš, da vmlinuz ni world-readable. Sej načeloma bootloader ničesar ne ve o permissionih filesistema...

The documentation for GRKERNSEC_HIDESYM has always mentioned restricting access to kernel image paths, as they can be abused by an attacker to determine targets for exploits just as /proc/kallsyms can be used. By enabling GRKERNSEC_HIDESYM, non-root users will automatically be prevented from reading kernel images/modules in /boot, /lib/modules, and the kernel source tree currently being built from. (vir: grsecurity
SELECT finger FROM hand WHERE id=3;

denial ::

/proc/kallsyms is now 400: KLIK.
SELECT finger FROM hand WHERE id=3;

Icematxyz ::

Potem ti ni všeč, kot varnostnem strokovnjaku ali pač nekomu, ki ga to področje zanima sama transparentnost zadeve. In ti to predstavlja varnostno grožnjo? Bi bilo bolje, če ne bi mogel te zadeve tako podrobno spremljati in morda celo sodelovati. Zapleteno vprašanje a ne da?

denial ::

@Icematxyz:
Ne mi polagat besed na jezik. Nikdar in nikjer nisem dejal da transparentnost predstavlja varnostno grožnjo oz. da mi transparentnost kode ni všeč. Prej obratno. Sem namreč mnenja, da informacijske varnosti ni mogoče zagotoviti samo s skrivanjem. Seveda pa velja tudi obratno: odprta koda samo po sebi še ni garancija za večjo varnost.

Sedaj pa si zadevo interpretiraj tako da bo kar najbolj ustrezalo tvoji FOSS/Linux mantri. Sam obdrži interpretacijo zase.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Icematxyz ::

denial je izjavil:

@Icematxyz:
Ne mi polagat besed na jezik. Nikdar in nikjer nisem dejal da transparentnost predstavlja varnostno grožnjo oz. da mi transparentnost kode ni všeč. Prej obratno. Sem namreč mnenja, da informacijske varnosti ni mogoče zagotoviti samo s skrivanjem. Seveda pa velja tudi obratno: odprta koda samo po sebi še ni garancija za večjo varnost.

Sedaj pa si zadevo interpretiraj tako da bo kar najbolj ustrezalo tvoji FOSS/Linux mantri. Sam obdrži interpretacijo zase.


Ni letelo na tebe direktno. To je splošna razprava in na kakšnih predvsem "javnih razpisih" pogosto zmaga argument, da odprta koda že sama po sebi pomeni varnostno tveganje. Ljudje so labilna bitja in se jim morda vse skupaj zdi celo logično. In potem se to lepo izrabi v klasične namene širjenja FUD. Za to sem to omenil. Ker ko podaš kakšno povezavo z razlago za kakšen "bug" v (F)OSS, preprosto ne morem, da ne bi tega dojemal, kot dodaten varnostni mehanizem, ki ga že sam po sebi zagotavlja (F)OSS. Ni to "FOSS/Linux mantra". Menim, da je kar dejstvo.

Pa še za kaj sem to sploh omenil. To je tisti pomemben vidik (F)OSS, ki se mu pripisuje beseda "varnost". Praksa pa potem loči zrno od plevela.

Se pravi če jaz spišem program, ki je ranljiv je vseeno če je na voljo kot "binary" ali je na voljo za ogled tudi "skladišče kode". Ranljivost se lahko v obeh primerih zlorabi. In to drugo varnost se zelo rado meša z "varnostjo" (kot dodano vrednostjo), ki jo zagotavlja (F)OSS.

Zgodovina sprememb…

denial ::

Kako ni letelo na mene direktno? Komu je tole namenjeno:
Potem ti ni všeč, kot varnostnem strokovnjaku ali pač nekomu, ki ga to področje zanima sama transparentnost zadeve. In ti to predstavlja varnostno grožnjo?

pogosto zmaga argument, da odprta koda že sama po sebi pomeni varnostno tveganje
Eh, to je bullshit MSFT fan-boyev. Za bug-research ne potrebuješ kode.

Za to sem to omenil. Ker ko podaš kakšno povezavo z razlago za kakšen "bug" v (F)OSS, preprosto ne morem, da ne bi tega dojemal, kot dodaten varnostni mehanizem, ki ga že sam po sebi zagotavlja (F)OSS. Ni to "FOSS/Linux mantra". Menim, da je kar dejstvo.
Ah, I see... "Given enough eyeballs all bugs are shallow" princip :D A ljudje še verjamejo v to?
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Icematxyz ::

Eh, to je bullshit MSFT fan-boyev.


Žal ni tako preprosto. To je argument, s katerim se zlorabi in izkrivlja dejstva prepogosto in prepoceni tudi pri resnih zadevah.

A ljudje še verjamejo v to?


Seveda. To je varnostni mehanizem, brez katerega verjetno sploh razprave o varnosti neke dotične stvari ne more biti. Brez tega se lahko samo slepo zaupa. To je pa tudi vse.

denial ::

Brez tega se lahko samo slepo zaupa. To je pa tudi vse.

Zadel si bistvo: zaupanje. A je pri FOSS/Linux kaj drugače? Kaj ne zaupaš kernel maintainerjem? Delaš sam audit kode? Pa si prepričan, da je tvoj code review kvaliteten in kompetenten? Večina Linux upotabnikov namreč zgolj nalaga binary paketke. Ker je koda open so pač prepričani, da jo bo itak pregledal nekdo, ki raztura zadevo in bo valda našel vse buge. Pa smo zopet pri slepem zaupanju.

V razmislek pa tole: there are people who eat Linux kernel bugs for breakfast. And they are not from FOSS community. Najbrž ima nekaj pri temu tudi ata Linus.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Icematxyz ::

there are people who eats Linux kernel bugs for breakfast


A samo Linux kosmiče imajo ljudje radi za zajtrk?

Zadel si bistvo: zaupanje. A je pri FOSS/Linux kaj drugače?


Seveda je drugače. Zakaj bi verjel na besedo? Kako že gre tisti rek. I have to see it to believe it.

Delaš sam audit kode? Pa si prepričan, da je tvoj code review kvaliteten in kompetenten?


Ne ti mi daš link glede bistvenih zadev občasno in si zadevo na to jaz pogledam. Sem že rekel hvala? Heh. Se pravi torej odgovor na tvoje vprašanje se glasi. Tudi sam delam "audit kode". Še v barvah je na primer razlika označena. Vem točno kje se je dogodila sprememba in kaj bo posledica. Še podnapise imam zraven. Temu jaz pač zaupam, da je to tisto pravo in ne obratno!

denial ::

Lepo. Sam na žalost vidiš le tisto kar je bilo objavljeno in posledično tudi patchano. There is always more... Evo, še dva linka: KLIK in KLOK. Enjoy reading :P

"It’s not clear from this sample that the kernel is getting more secure over time. I suspect we’re getting better at finding bugs, particularly now that companies like Google are paying researchers to audit the kernel, but it’s not obvious we’re getting better at not introducing them in the first place."
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Icematxyz ::

There is always more...


No sem si prebral ti dve povezavi, ki si jih podal. In me veseli, da vidim koliko energije in znanja so nekateri ljudje pripravljeni vložiti v to, da bo sam "varnostni model" še boljši in to prav na področju GNU/Linux, ki že tako na področju "varnosti" in varnosti v praksi izpolnjuje visoke norme. Jaz na teh dveh povezavah vidim kvečjemu argument, da bo v GNU/Linux ekosistemu stanje na tem področju spodbudno tudi v prihodnosti!

Zgodovina sprememb…

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Ubuntu 10.10 - 10 Out Of 10 (strani: 1 2 3 4 … 19 20 21 22 )

Oddelek: Operacijski sistemi		1093168118 (125711) Icematxyz
»

Ubuntu 10.04 LTS - Change is coming (strani: 1 2 3 4 … 17 18 19 20 )

Oddelek: Operacijski sistemi		999141170 (104056) Icematxyz
»

Ubuntu 11.04 Natty Narwhal (strani: 1 2 3 4 … 17 18 19 20 )

Oddelek: Operacijski sistemi		981178440 (151087) Icematxyz
»

Izšel Ubuntu 11.04 (strani: 1 2 3 4 5 )

Oddelek: Novice / Operacijski sistemi		20650998 (40860) Icematxyz
»

Izšel Ubuntu 10.10 (strani: 1 2 3 4 5 )

Oddelek: Novice / Operacijski sistemi		22168157 (58241) Icematxyz

Več podobnih tem