Krytyczna dziura we FreeBSD
- Dodano: 13 lipca 2010
- Wprowadził: mangoo
- Komentarze: 90
Błąd w zarządzaniu pamięcią w podsystemie sieci we FreeBSD umożliwia edycję plików przez użytkowników nie posiadających do nich praw zapisu.
W efekcie możliwe jest przejęcie praw administratora systemu.
Problem dotyczy FreeBSD w wersji 7.x i późniejszych.
Zaleca się uaktualnienie systemów do wersji 7-STABLE lub 8-STABLE.
Więcej informacji: http://security.freebsd.org/advisories/F...7.mbuf.asc
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
90 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
No ale oczywiście BSD od lat niewykryta żadna luka … ciągle to słyszę od zwolenników BSD. Niestety jakby dokładnie przejrzeć securityfocus to ostatnio trochę tych błędów wyszło. Czyli jednak systemy te nieróżną się od innych jak Linux czy Windows.
Roznia sie iloscia bledow. Pozwol, ze zacytuje ci ostatnie advisory RHEL-a:
* multiple flaws were found in the mmap and mremap implementations. A local
user could use these flaws to cause a local denial of service or escalate
their privileges. (CVE-2010-0291, Important)
* a NULL pointer dereference flaw was found in the Fast Userspace Mutexes
(futexes) implementation. The unlock code path did not check if the futex
value associated with pi_state->owner had been modified. A local user could
use this flaw to modify the futex value, possibly leading to a denial of
service or privilege escalation when the pi_state->owner pointer is
dereferenced. (CVE-2010-0622, Important)
* a NULL pointer dereference flaw was found in the Linux kernel Network
File System (NFS) implementation. A local user on a system that has an
NFS-mounted file system could use this flaw to cause a denial of service or
escalate their privileges on that system. (CVE-2010-1087, Important)
* a flaw was found in the sctp_process_unk_param() function in the Linux
kernel Stream Control Transmission Protocol (SCTP) implementation. A remote
attacker could send a specially-crafted SCTP packet to an SCTP listening
port on a target system, causing a kernel panic (denial of service).
(CVE-2010-1173, Important)
* a flaw was found in the Linux kernel Transparent Inter-Process
Communication protocol (TIPC) implementation. If a client application, on a
local system where the tipc module is not yet in network mode, attempted to
send a message to a remote TIPC node, it would dereference a NULL pointer
on the local system, causing a kernel panic (denial of service).
(CVE-2010-1187, Important)
* a buffer overflow flaw was found in the Linux kernel Global File System 2
(GFS2) implementation. In certain cases, a quota could be written past the
end of a memory page, causing memory corruption, leaving the quota stored
on disk in an invalid state. A user with write access to a GFS2 file system
could trigger this flaw to cause a kernel crash (denial of service) or
escalate their privileges on the GFS2 server. This issue can only be
triggered if the GFS2 file system is mounted with the "quota=on" or
"quota=account" mount option. (CVE-2010-1436, Important)
* a race condition between finding a keyring by name and destroying a freed
keyring was found in the Linux kernel key management facility. A local user
could use this flaw to cause a kernel panic (denial of service) or escalate
their privileges. (CVE-2010-1437, Important)
* a flaw was found in the link_path_walk() function in the Linux kernel.
Using the file descriptor returned by the open() function with the
O_NOFOLLOW flag on a subordinate NFS-mounted file system, could result in a
NULL pointer dereference, causing a denial of service or privilege
escalation. (CVE-2010-1088, Moderate)
* a missing permission check was found in the gfs2_set_flags() function in
the Linux kernel GFS2 implementation. A local user could use this flaw to
change certain file attributes of files, on a GFS2 file system, that they
do not own. (CVE-2010-1641, Low)
W sumie szesc eksploitowalnych dziur. Przyznasz, ze jest pewna roznica.
@trasz: przyznasz, że projekt RH to lekko większe przedsięwzięcie niż FB, więc porównania ilościowe możesz sobie darować.
@trasz: tak szczerze- od kiedy wiedzą o tym błędzie źli ludzie? Patrząc na ilość podatnych wersji, prawdopodobnie od miesięcy. Czy jak zwykle czegoś nie rozumiem.
No co ty. O błędach we FreeBSD źli ludzie dowiadują się w chwili wydania advisory, z uwagi na świetny security team
@Tomasz Woźniak: Z tego co widze, to blad zostal znaleziony przedwczoraj przez jednego z developerow FreeBSD. To nie jest oczywisty blad programistyczny widoczny na pierwszy rzut oka, jak w przypadku niedawnego problemu z Ubuntu.
A co do porownan ilosciowych – probujesz powiedziec, ze krytyczne luki w wiekszym projekcie sa mniej grozne niz w mniejszym? ;->
@Tomasz Woźniak: A nie, zle spojrzalem. Blad byl znany wczesniej, kilka dni temu po prostu byl omawiany na ircu. Ale nadal.
oj naiwni, naiwni
źli ludzie interesują się tylko błędami w linuksie (zwłaszcza ubuntu)
słowo unix działa na nich jak raid na komary
@Tomasz Woźniak: Ciezko powiedziec. Problem wyplynal mniej wiecej tydzien temu. Dziura nie jest oczywista na pierwszy rzut oka – inaczej niz niedawna dziura w Ubuntu, wiec nie wiadomo, czy ktos znalazl ja wczesniej i zachowal dla siebie.
@trasz: odniosę się tylko do porównania ilościowego błędów.
Podejrzewam panie Edwardzie, że dobrze pan wie o co mi chodzi. Załóżmy, że mamy 2 domy- jeden to 4 piętrowy blok a drugi to 30 piętrowy biurowiec. Zakładamy, że oba wykonane są solidnymi technikami i z dbałością o jakość. Teraz zacznijmy porównywać ilość poprawek jakie trzeba wykonać (bo nie tylko programiści popełniają błędy, ale budowlańcy też). Jak pan myśli- ilościowo gdzie będzie takich poprawek więcej? Odpowiem- w biurowcu. Wynika to z całej masy rzeczy- przede wszystkim skali, ilości firm pracujących i zakresie działania.
Tak samo z porównywaniem FreeBSD do RH- swoją drogą dlaczego nie do SLES? Sam musi przyznać, że projekt samego jądra to znacznie więcej niż cały FreeBSD.
No
Nie mogłem się doczekać, aż coś się przytrafi w którymkolwiek BSD. I jak na zawołanie. Ale _UWAGA_!!!! TO NIE JEST TRYWIALNA LUKA.
Traszu, nie podpieraj się proszę statystykami itd. wszystkie systemy mają błędy. Niedawno można było przeczytać o lukach bezpieczeństwa w bazie Oracle Enterprise z opcjami Security Vault itd. Certyfikowana do zastosowań wojskowych itd. Błędy się zdarzają.
Przyznaj po prostu, że zżymasz się na fakt, że Linux idzie do góry, natomiast BSD nie. Na pocieszenie podam fakt, że ze statystyk wynika, że Windows idzie do góry szybciej niż Linux.
BSD (przynajmniej FreeBSD) idzie do przodu i ma się całkiem nieźle, na jakiej podstawie napisałeś, że nie?
to znowu czeka nas rok linuksa? 0_o
Czy linuks jest jakimś nowym znakiem w chińskim zodiaku?
@trsh
liczby nie mowia tego jak latwo blad wykorzystac.
Splice jest podstawowa funkcja
a tutaj co podales:
dwie sa do gfs2, a jeszcze nie widzialem aby ktos tego uzywal wiec raczej jest dosyc zadko stosowane rozwiazanie.
blad na Tipc opiera sie na wyscigu podczas ladowania modulu wiec tez jest bledem zadkim.
nfs i sctp od biedy mozna uznac za funkjonalnoscia podstawowa.
Jedynie futexy i remap daje ci pewnosc ataku.
Wiec z 6 zrobily sie 2 dziury.
A tak btw prosze o niestosowania kilkustronicowych komentarzy zle sie je czyta.
Wiesz, wyzej opisana dziura we FreeBSD tez nie daje ci "pewnosci ataku" – wykorzystanie jej do podniesienia uprawnien (zakladajac, ze jest to mozliwe – teoretycznie jest) wymagaloby niezlego kombinowania.
Mistrzu, ale jeśli możliwa jest "edycja plików przez użytkowników nie posiadających do nich praw zapisu", to spokojnie można spobie podnieść uprawnienia. Na przykład edytując /etc/shadow i usuwając hasło roota. Tak?
PWNED
@wiktorw: Wlasnie problem w tym, ze nie do konca. Uzywajac tej luki mozna bardzo latwo _uszkodzic_ pliki, natomiast ciezko wykombinowac, jak je zmodyfikowac w sposob kontrolowany przez atakujacego. To nie jest tak, jak z luka w Ubuntu, ze po prostu zrobisz pare prostych krokow i otworzysz /etc/shadow vimem – tutaj mamy do czynienia z kernelem nadpisujacym kawalek pliku czymstam.
Z tego, co rozumiem, to można _zapisywać_ modyfikacje plików, które użytkownik mógł tylko _czytać_. /etc/shadow nie możesz czytać jako zwykły user. Bardziej prawdopodobny atak to podniesienie sobie uprawnień poprzez dopisanie się do odpowiednich grup, lub coś w tym stylu.
Nie jest to takie proste do wykonania jak ostatni błąd w pam_motd
Nie pam_motd, tylko wersji zmodyfikowanej na potrzeby Ubuntu. Więc to żaden błąd Linuksa.
A artykuł jest o błędzie konkretnie w BSD.
Trochę różnica.
A łatwość wykorzystania nie ma nic do rzeczy. No chyba, że BSD wyznaje politykę "security by users' stupidity".
nie zapedzaj sie poza free masz jeszcze open/net/desktop i kilka innych bsd ktre potrafia sie od siebie znacznie roznic …
blad jest w implementacji freebsd tak samo jak problem motd dotyczyl tylko ubuntu.
Z tego co czytalem (byc moze mam zle zrodlo) blad w ubuntu pozwalal na odczytanie dowolnego pliku,natomiast blad w freebsd pozwala na zmodyfikowanie dowolnego pliku. Niby spora roznica jednak z punktu widzenia napastnika tak naprawde niewielka.
@ak47: gwoli ścisłości, to relacja między dystrybucjami Linuksa jest inna niż pomiędzy systemami z rodziny BSD. Luka w Ubuntu była na poziomie dystrybucji, luka we FreeBSD jest na poziomie systemu, więc dotyczy zapewne również jego dystrybucji, jak DesktopBSD czy PC-BSD.
luka z ubuntu takze dotykala kubuntu/xubuntu/itp oraz setki "domowych" przerobek wiec sytuacja jest jak najbardziej analogiczna.
dorzucić wypada jeżeli luka dotyczy kernela problem może wystąpić też w Debianie z tym kernelem
@ak47
Twój argument jest bezsensowny. Ubuntu/Kubuntu/Xubuntu itp. wszystkie korzystają z tych samych repozytoriów, więc naturalne, że będą dziedziczyć te same błędy. Linuksowe dystrybucje używają natomiast tego samego jądra, w przeciwieństwie do trzech głównych *BSD, które mają swoje własne.
@bobycob
Bzdury piszesz, trollu.
dlaczego trollu?
dlaczego bzdury – Debian w wersji z kernelem freebsd będzie odporny na błędy w tym kernelu?
@ak47: błąd w pam_motd zmieniał ownera pliku.
oczywiście BSD od lat niewykryta żadna luka … no po trochu to prawda jezeli chodzi o prawdziwy BSD czyli OpenBSD – reszta to komercyjny chłam dla nastolatków i gospodyń dowmowych szczególnie netbsd które to gospodynie uwielbiają instalując na testerach , pralkach itp . FReeBSD to wiadomo sataniści
Mam nadzieje, że to tylko sarkazm
raczej nawiązanie do maskotki
Dobrze waszmość powiadasz, wódki waszmościowi nalać. OpenBSD uber alles!
OpenBSD to i tak fork NetBSD
A openbsd instalują w ogóle gdzieś? Poza tym nie porównywałbym go do żadnych poważnych systemów, ponieważ nadaje się głównie na mały serwer.
Pewno tak. Trudno powiedziec (sprawdzic). Jakis tam udzial w rynku na pewno ma- inaczej przestal by istniec.
Tu tez masz troche racji jesli chodzi o serwery i wydajnosc- OpenBSD ma srednio udany SMP- niby dziala a i tak sie nie skaluje tak jak SMP w FreeBSD czy NetBSD wiec sami sobie troche ograniczaja obszar zastosowan.
Z drugiej strony OpenBSD to maly projekt- "malo" ludzi nad nim pracuje a maja niezle rozwiazania. I mysle, ze Theo ma racje jesli chodzi o rozwiazania bezpieczenstwa systemo itd.
Ale do rzeczy, dziura jest, latka jest wiec zrobic update i dziala
To znajdzmi taką gospodynie co potrafi zainstalować i skonfigurowac NetBSD, chociażna desktopie i z jakimś openboxem. No chyba że ma w małym palcu edytor Vi to szacun.
Łatka odrazu jest wiec nie widze problemu, tym bardziej, ze dziura trudna do użycia i na pewno nie tak spektakularna jak ta z ubuntu.
Dziura jest trywialna do uzycia:
http://www.listware.net/201007/freebsd-net/21068-…
Zakladajac, ze mamy dostep do webserwera (PHP, Perl etc.) z dostepem jedynie przez FTP.
Wrzucamy "exploita", uruchamiamy go np. z argumentem "/etc/passwd", i administratora czeka podroz do serwerowni…
A jak mamy konto lokalne / dostep SSH, to juz w ogole robi sie ciekawie.
Choc trzeba zaznaczyc, ze podany kod jedynie "popsuje" dane pliki – i to jest druga strona tego problemu – zaaplikowanie latki nie naprawi przeciez plikow, ktore przypadkowo zostaly popsute miesiace wczesniej, na skutek zlej implementacji "sendfile".
a co za włamywacz ma konto FTP na serwerze który atakuje? O_o i od kiedy ftp czy www admin nie trzyma w chroocie?
W przypadku tej dziury z Ubuntu atakujący musi mieć konto użytkownika i nie budzi to twoich wątpliwości.
"a co za włamywacz ma konto FTP na serwerze który atakuje?"
Jak bug w Ubuntu wymagał bezpośredniego dostępu do konta użytkownika w systemie, to była wielka dziura i tragedia.
Jak ten nawet nie wymaga dostępu do shella, a wystarczy ftp+httpd (czyli standard), to trzeba zapluć krytykujących, bo przecież BSD nie może mieć błędu.
No i nie ma, przecież go naprawili :>
konto to jedno, drugie to, ze nieznam systemu gdzie admin by nie trzymał demonow sieciowych w chroocie, tymbardziej, ze jest to obecnie domyślna konfiguracja ;] Natomiast w domyślnej konfiguracji Ubuntu mając dowolne konto, masz dostęp do roota. Wniosek jeden, w przypadku FreeBSD trzeba być idota by sobie tak skonfigurować system i udostepnić jeszcze komuś obcemu konto ftp/www, w przypadku ubuntu – wystarczy ssh lub fizyczny dostęp, czynnik dot. admina niema znaczenia.
> Natomiast w domyślnej konfiguracji Ubuntu mając dowolne konto, masz dostęp
> do roota
@konski_pyton: no to analogicznie jak we FreeBSD – wystarczy SSH lub fizyczny dostep.
A konta FTP/WWW bez dostepu do shell sa jednak bardzo popularne np. w hostingu.
Każda usługa powinna działać w jailu, być osobno, np osobno ftp, osobno http i tylko podmontowane razem z nullfs (jednokierunkowo – httpd nie może nic nadpisać bo jest read-only).
A jak już coś ktoś zepsuje to rsync/unison z backupów i ezjail stop $jail; ezjail-admin delete -w $jail; ezjail-admin create $jail $jailip; ezjail start $jail;
(w końcu basejail i flavors są bezpieczne, nikt by ich nie narażał prawda?)
Więc ten wasz atak z dostępem do httpd+ftp nie zadziała, a jak w inny sposób ktoś podmieni /etc/master.passwd czy inny sudoers to czysty jail mamy w ciągu 3 sekund, następne kilkadziesiąt na przywrócenie wszystkich paczek i trochę czasu na przywrócenie backupów, w zależności od ich wielkości.
Tak naprawdę na bsd można dać komuś roota a i tak nie będzie w stanie rozwalić systemu – okazuje się że to root w jailu…
tylko w FreeBSD domysle masz jaila wiec ta dziura istnieje tylko tam gdzie debil (bo na pewno nie administrator) robi hosting bez jaila, który jest domyślny.
@Marek Czarek: Dziura jest trudna do uzycia, bo powyzsze, to tylko lokalny DoS. Nad podniesieniem w ten sposob uprawnien musialbys troche dluzej popracowac.
@Marek Czarek: Dziura jest bardzo trudna do uzycia. To, co wkleiles powyzej, daje ci tylko lokalny DoS. Nijak to sie ma do podniesienia uprawnien.
@konski_pytong: a błąd w Ubuntu tyczył tylko jednej konkretnej wersji, a nie całej rodziny. Co to za tłumaczenie? Ktoś pisze, że FB ma gorszy błąd niż Ubuntu?
Czasami odnoszę wrażenie, że bsdiciarze są gorsi od sekciarzy.
>FReeBSD to wiadomo sataniści
A OpenBSD to wiadomo – wędkarze.
Nie, to theo-kraci
Tylko w przypadki FreeBSD wyszła łatka zanim rootkity
Chciałbym, żebyś miał rację, ale nigdy nie wiadomo czy i ile czasu wcześniej źli ludzie wiedzieli o błędzie. Szczególnie, że dziura jest dość wiekowa.
@konski_pytong: a bijesz do tego Ubuntu ponownie? Akurat podatność na taką lukę jest od dość dawna patrząc na ilość wersji jakie obejmuje.
@trasz
> Roznia sie iloscia bledow. Pozwol, ze zacytuje ci ostatnie advisory RHEL-a:
Nie stać Cię na support do linuxa i dorabiasz ideologię.
@Trasz
Nic dziwnego, że znalazłeś tyle raportów skoro dotyczą nawet różnych systemów plików. W bsd ile ich jest? Jeden z epoki kamienia łupanego bo zanim da się normalnie korzystać z zfs to minie sporo czasu. Zwróć uwagę na to, że przy Linuksie pracuje znacznie więcej osób i znacznie więcej osób z niego korzysta więc tym samym istnieje ZNACZNIE większa szansa wykrycia luki niż w przypadku freebsd a tym bardziej openbsd. Poza tym RHEL nie jest jakąś zabawką dla fanboyów więc przykłada się znacznie więcej uwagi w wykrywaniu luk.
@Pawel: Systemu plikow niewspieranego przez FreeBSD dotyczy tylko jedna z tych dziur. ZFS jest uzywalny (i uzywany produkcyjnie) od dosyc dawna, a ext4 dopiero niedawno dopedzil UFS pod wzgledem funkcjonalnosci. Proponuje sie douczyc zamiast powtarzac zaslyszane haselka
Swoja droga, interesujace, ze mit "community audit" nadal zyje w sercach Linuksiarzy, mimo ze – wydawaloby sie – dawno go obalono. FYI: ilosc kompetentnych osob przegladajacych kod systemu w poszukiwaniu dziur jest bardzo niewielka. W praktyce niewiele luk znajduje sie w ten sposob.
Możesz rozwinąć, dlaczego nie można normalnie korzystać z ZFSa w tym momencie ?
@Pawel: Jakie ma znaczenie, ile ich jest? Wazne, ze funkcjonalnie dopiero ext4 zblizyl sie do FreeBSD-owego UFS-a (ktory wlasnie znow sie oddalil dzieki SUJ, laczacemu zalety softupdates i journallingu; ext4 nadal uzywa najprostszego journallingu na poziomie calych blokow). Odpowiednika funkcjonalnego ZFS-a pod Linuksem nadal nie ma; Btrfs rozwija sie powoli, ale juz posiada znane bledy projektowe, ktore byc moze beda wymagaly przemyslenia calosci od zera. Poza tym tylko jedna z w/w dziur w Linuksie byla zwiazana z systemem plikow niedostepnym pod FreeBSD.
funkcjonalnie to moze i sie zblizyli (ufs2,ext4), choc ext4 wspiera extents. Natomiast wydajnosciowo to ufs2 dalej pozostaje w tyle
http://www.phoronix.com/scan.php?page=article&…
@Trasz
Co to? Aż tyle krytycznych luk w przeciągu kilku miesięcy?
CVE-2010-2693
II. Problem Description
The read-only flag is not correctly copied when a mbuf buffer reference
is duplicated. When the sendfile(2) system call is used to transmit
data over the loopback interface, this can result in the backing pages
for the transmitted file being modified, causing data corruption.
III. Impact
This data corruption can be exploited by an local attacker to escalate
their privilege by carefully controlling the corruption of system files.
It should be noted that the attacker can corrupt any file they have read
access to.
CVE-2010-2020
II. Problem Description
The NFS client subsystem fails to correctly validate the length of a
parameter provided by the user when a filesystem is mounted.
III. Impact
A user who can mount filesystems can execute arbitrary code in the kernel.
On systems where the non-default vfs.usermount feature has been enabled,
unprivileged users may be able to gain superuser ("root") privileges.
CVE-2010-1938
III. Impact
An attacker can remotely crash a service process which uses OPIE when
stack protector is enabled.
Note that this can happen even if OPIE is not enabled on the system,
for instance the base system ftpd(8) is affected by this. Depending
on the design and usage of OPIE, this may either affect only the
process that handles the user authentication, or cause a Denial of
Service condition.
It is possible but very unlikely that an attacker could exploit this to
gain access to a system.
CVE-2010-2022
II. Problem Description
The jail(8) utility does not change the current working directory while
imprisoning. The current working directory can be accessed by its
descendants.
III. Impact
Access to arbitrary files may be possible if an attacker managed to obtain
the descriptor of the current working directory before the jail call.
Such descriptor would be inherited by all descendants of the first process
that starts the jail, unless an intermediate process changes the current
working directory inside the jail.
By default, the FreeBSD /etc/rc.d/jail script, which can be enabled
using the jail_* rc.conf(5) variables, is not affected by this issue.
This is due to the default jail flags ("-l -U root") used to start a
jail as these flags will result in jail(8) performing a chdir(2) call.
If the rc.conf(5) variables jail_flags or jail__flags has been
set, and do not include '-l -U root', the jails are affected by the
vulnerability.
CVE-2009-3563
II. Problem Description
If a client requests DNSSEC records with the Checking Disabled (CD) flag
set, BIND may cache the unvalidated responses. These responses may later
be returned to another client that has not set the CD flag.
III. Impact
If a client can send such queries to a server, it can exploit this
problem to mount a cache poisoning attack, seeding the cache with
unvalidated information.
A tutaj mistrzostwo:
http://www.zdnet.com/blog/security/exploit-publis…
Jeszcze bardziej lamerska luka niż w przypadku Ubuntu!
oj nie kop leżącego
bidula teraz w odpowiedzi na swoje utyskiwania wobec linuksa będzie od kogoś link do tego newsa dostawał aby pamięć odświeżyć.
@letyns: Zdajesz sobie sprawe, ze zacytowales liste bledow FreeBSD z ponad roku, a ja dluzsza liste dziur w samym kernelu Linuksa z dwoch miesiecy? ;->
@letyns: Ale zdajesz sobie sprawe, ze wkleiles liste dziur we FreeBSD z roku, a ja dluzsza liste dziur w samym kernelu Linuksa z dwoch miesiecy? ;->
O, to prawdziwy cios dla FSF… =} :
http://www.fsf.org/working-together/gang/freebsd
Widze, ze z osnews.pl zrobilo sie kompletne FUDarium i masturbatorium nad Linuxem, FreeBSD w 2009 mialo 9 SA (security advisory), Red Hat Enterprice Linux 5.x mial ich 742 … http://www.redhat.com/security/data/cve/cve-2009….
Oczywiscie sa tam tez takie pozycje jak firefox/webkit ale wystarczy sobie odfiltrowac te 'desktopowe' a i tak wyjdzie tego mnostwo …
> FreeBSD w 2009 mialo 9 SA (security advisory),
> Red Hat Enterprice Linux 5.x mial ich 742 …
Smiem twierdzic, ze te liczby odzwierciedlaja rowniez
proporcje w rozpowszechnieniu tych systemow.
Linucha wiecej, to i wiecej smiecia w nim wydlubuja.
Windows jeszcze wiecej, a dziur – nie. Cos nie tak z twoja teoria.
@jarek: przede wszystkim te liczy mówią o wielkości projektów FreeBSD lubi się porównywać do RH, ale to pewnie po to by siebie nobilitować.
@jarek: Popularnosc Windows jest znacznie wieksza niz Linuksa, a dziur w nim – minimalnie mniej. Nie uwazasz, ze cos jest nie teges z twoim kryterium popularnosci?
(Drodzy admini OSNews.pl, moglibyscie moze naprawic, zeby komentarze nie ginely?)
@rhel: po pierwsze- te projekty są nieporównywalne wielkością. Po drugie- jak przytaczasz listę, to sam sobie odfiltruj i porównaj, a nie siej propagandowej durnoty z niesprawdzalną liczbą.
Po trzecie- to nie Linuksiarze siedli na BSDarzy, ale BSDarze na Linuksiarzy- przeczytaj sobie wypowiedzi trasza i koła anty Linuksiarskiego w wątku o błędzie na Ubuntu. Teraz w komentarzach ludzie dają odpust tamtym emocjom- i słusznie. Należy się.
Co do masturbatorium- nie przeginasz z semantyką?
Odfiltruj tyle, żeby pozostały jedynie te, które wchodzą w skład freebsd to nie będzie ich tak dużo. Ponadto, RHEL i w ogóle dystrybucje Linuksa mają ZNACZNIE większy audyt od *BSD, ponieważ *BSD nie istnieją w sektorze enterprise a tam bezpieczeństwo jest bardzo ważne. Kiedyś scan zrobił raport na temat jakości kodu i wyszło na to, że kod Freebsd jest znacznie gorszej jakości od kodu Linuksa (liczba błędów/1k lini kodu).
Nie istnieje?
Who Uses FreeBSD?
FreeBSD is used as a platform for devices and products from many of the world's largest IT companies, including:
•Apple
•Cisco
•Juniper
•NetApp
FreeBSD is also used to power some of the biggest sites on the Internet, including:
•Yahoo!
•Yandex
•Apache
•Rambler
•Sina
•Pair Networks
•Sony Japan
•Netcraft
•NetEase
•Weathernews
•TELEHOUSE America
•Experts Exchange
and many more.
Repost, bo komentarze gina. Michuk i s-ka – cos wam ten serwer na GPL-u niespecjalnie dziala ostatnio.
@letyns: Problem w tym, ze bedzie – ilosc dziur w samym kernelu Linuksa jest wielokrotnie wieksza niz liczba dziur we FreeBSD (calym). Powyzej wkleilem liste dziur w kernelu RHEL-a z dwoch miesiecy, ktora jest mniej wiecej taka, jak wklejona nieco nizej lista dziur we FreeBSD z ponad roku.
BSD jak najbardziej istnieja w sektorze enterprise – wieksza czesc sieci szkieletowych dziala na pochodnej FreeBSD, cala masa IDS-ow i IPS-ow dziala na pochodnej FreeBSD, podobnie jak cala masa enteprise'owych NAS-ow. Superkomputerom produkcji SGI pochodna FreeBSD serwuje storage. Linux ma tam mniejszy udzial – zgadnij, dlaczego. Ma za to duzy udzial w zabawkowych routerkach (Linksys itp).
A co do audytu – sorry, ale mit o "community audit" zostal obalony dawno temu. A co do Coverity – to fajny wynalazek marketingowy, ale tylko marketingowy, bo Coverity potrafi miec bardzo rozna liczbe false positives, ktorej nie da sie oszacowac i ktora przeklamuje wyniki.
http://technologie.gazeta.pl/internet/1,104530,81…
solaris ostatnim bastionem
W podlinkowanym artykule stoi, że teraz statystyka firmy Secunia wygląda tak:
1. Apple
2. Oracle (w tym Solaris?)
3. Microsoft
Oby.
Podsumowując wojnę BSD- Linux:
Ale niektórzy mają uciechę:)
Dla upartych pozostaje jeszcze haiku albo minix
Boli mnie w tym wszystkim coraz częstsze znajdywanie banalnie prostych luk we freebsd , oby cały projekt nie zeszedł na zły tor
Mozesz podac przyklad takiej "banalnie prostej luki" znalezionej ostatnio we FreeBSD?
Ta jest banalna, była niedawno jeszcze jedna co można sobie było roota zdobyć mając lokalny dostęp. Poza tym wpisz siebie w google "exploit freebsd" trochę tego znajdziesz.
http://www.heise-online.pl/security/news/item/Exp…
oo nie tak dawno
na szczęście miałem zbyt stary system na serwerze na tego buga, ale potem go zaktualizowałem i dorobiłem się tego o czym mowa w tym newsie. Przyznam się że nienawidzę FreeBSD, pieszczotliwie nazywam go FreeSyf 
@Lashlo: Luka w rtld nie jest banalnie prosta, wrecz przeciwnie – pojawila sie na skutek dosyc skomplikowanego splotu wydarzen (pewna funkcja zostala zmodyfikowana w taki sposob, aby zwracala blad zamiast konczyc wykonywanie; wszystkie wywolania zostaly zmodyfikowane – ale tylko to, co bylo w glownej galezi; jakis czas pozniej zmerge'owano inny kod, ktory zmodyfikowany nie zostal). Dla porownania, dziura w Ubuntu to podrecznikowy blad programistyczny, ktory pokazuje, ze ani autor, ani hipotetyczny reviewer nie doczytali o podstawach bezpieczenego programowania.
Więc teraz porównujesz freebsd z ubuntu…
Jesteś genialny
FreeBSD zawsze uchodziło za jeden z najbezpieczniejszych systemów. Ale to może dlatego, że jego udział w rynku jest niewielki.
I loved as much as you’ll receive carried out right here. The sketch is attractive, your authored material stylish. nonetheless, you command get bought an impatience over that you wish be delivering the following. unwell unquestionably come further formerly again as exactly the same nearly very often inside case you shield this increase.