Firefox do likwidacji - Mozilla zwalnia cały zespół bezpieczeństwa

[Laos]

Mozilla zwolniła 250 osób w tym m.in cały zespół bezpieczeństwa Firefoxa.
Zamiast skupiać się na przeglądarce, mają produkować nowe programy komercyjne pozwalające utrzymać się finansowo Mozilli.

Panie premierze, jak żyć bez Firefoxa ?

[jacekalex]

Pożyjemy zobaczymy.

FF na razie istnieje, i pewnie będzie dalej istniał, tylko łatki poprawiąjące bezpieczeństwo będą tworzyć freelancerzy.
Z resztą nie warto przeceniać zespołu bezpieczeństwa, w tej chwili starcza, że przeglądarka nie pozwala wykradać haseł i zakładek.Jeśli każda karta tworzy osobny proces przeglądarki, to 80% roboty z bezpieczeństwem przeglądarki przestaje być potrzebna.
W dodatku np w Linuxie FF jest chroniony przez mechanizmy systemowe - Apparmor lub SElinux, także seccomp.
W Androidzie masz SELinuxa i seccomp, a WIndowsa już chyba nikt poważnie nie traktuje, to też powoduje,
że w FF zespól bezpieczeństwa ma znacznie mniejsze znaczenie, niż kiedyś.

Także nie ma się czym martwić, w dodatku na świecie jest trochę istot rozumnych, które rozumieją, ze nie można zostawić przeglądrki WWW na jednym jedynie słusznym silniku Chrome, który produkuje jedna korporacja.

Zwłaszcza po tym, jak cała GAFA została zaproszona przed Komisję Senacką w USA w związku z dochodzeniem antymonopolowym.Jeżeli amerykańscy senatorzy wyciągnęli z szuflady ustawę Shermanna, to kasa na pomoc Mozilli na pewno się znajdzie.
Pewnie z resztą Mozilla zwalnia głównie tęczowatych, niebinarnych specjalistów, których w przeszłości przyjęła zbyt dużo.


Pozdro

[enedil]

Ja z kolei myślę, że jak tak gadasz, to Ciebie, Jacku, ciężko brać na poważnie. Również myślę że skutki tych zwolnień mogą być przecenione, ale jednocześnie redukcja bezpieczeństwa do ustawienia odpowiednich filtrów seccompa czy ochrony haseł, to nadużycie. Nie trzeba szukać daleko żeby znaleźć historię luk w kompilatorach JIT JSa, które pozwalały na ucieczkę z sandboxa, a na blogu Projektu Zero Googla niedawno były artykuły o tym jak na FF na Windowsie dało się uciec z sandboxa, bo izolacja procesów źle brała pod uwagę istnienie procesu renderers GPU. Bezpieczeństwo nie jest trenerem zamkniętym

[jacekalex]

Nie trzeba szukać daleko żeby znaleźć historię luk w kompilatorach JIT JSa, które pozwalały na ucieczkę z sandboxa, a na blogu Projektu Zero Googla niedawno były artykuły o tym jak na FF na Windowsie dało się uciec z sandboxa, bo izolacja procesów źle brała pod uwagę istnienie procesu renderers GPU. Bezpieczeństwo nie jest trenerem zamkniętym

W Biblii kiedyś napisali, żeby dom budować na skale, a nie na ruchomych piaskach.
Błędy się zdażają wszędzie, ale cała platforma WIndows to są właśnie ruchome piaski, gdzie wszystkie tzw "zabezpieczenia" są nakładkami na system, a nie jego rdzeniem.
Miedzy rdzeniem a nakładkami zawsze jest jakaś luka, to sytuacja całkiem naturalna.

Właśnie dlatego Linux cały system uprawnień systemowych i LSM trzyma w kernelu, a nie w zewn sterownikach i userspace.
Identycznie postępują systemy z rodziny BSD, potem zarówno Android jak i ISO działają w internecie bez antywirusa 5 lat a nie 15 minut.
Dlatego nie masz co porównywać aplikacji na platformie WIndows od aplikacji w innych systemach, bo nie da się oddzielić jakości i trwałości stołu od jakości i trwałości podłogi, na której stoi.
Rozdzielnie zakładek na osobne procesy likwiduje 95% problemów z bezpieczeństwem wewnątrz aplikacji,
z którymi borykali się programiści wcześniej, bo po prostu wyrzuca je z wnętrza aplikacji na poziom systemu opracyjnego.

Inna sprawa, że to system operacyjny odpowiada za to, żeby jedne procesy systemowe nie mogły wykradać danych innych procesów systemowych.
Systemów operacyjnych Windows, Linux, BSD czy Android Mozilla na razie nie produkuje.

Jeżeli mechanizm Sandbox w Windows albo mechanizm Namespaces w Linuxie będzie miał błędy,
to będzie wina Mozilli czy systemu operacyjnego?

PS:
RTFW:
https://en.wikipedia.org/wiki/Linux_namespaces

PS2:

Other applications, such as Google Chrome make use of namespaces to isolate its own processes which are at risk from attack on the internet [12].

Mozilla się po prostu uczy od konkurencji i tym samym prawie cały problem bezpieczeństwa przeglądarki wynosi piętro wyżej, na poziom systemu operacyjnego.
Sam FF natomiast wraca z poziomu aplikacji pracującej na wielu zakładkach co wprowadziło tysiące problemów z bezpieczeństwem, na pozycję typu jeden proces - jedna zakładka, który znamy z Netscape i FF do wersji >3.0
Ma teraz jedynie wspólne okienko, te poszczególne procesy wyświetla w zakładkach.

Otwarte 3 karty FF u mnie:

Kod: Zaznacz cały

pacjent      964  3.2  3.1 3354100 504884 tty7   Sl   04:18   4:59 /usr/lib64/firefox/firefox -P pacjent --new-tab
pacjent      998  1.7  1.0 909644 160632 tty7    Sl   04:18   2:40 /usr/lib64/firefox/firefox -contentproc -parentBuildID 20200811042452 -prefsLen 1 -prefMapSize 426224 -appdir /usr/lib64/firefox/browser 964 gpu
pacjent     1048  1.0  2.0 34475796 323620 tty7  Sl   04:18   1:36 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 126 -prefMapSize 426224 -parentBuildID 20200811042452 -appdir /usr/lib64/firefox/browser 964 tab
pacjent     1622  0.6  1.3 2833392 207324 tty7   Sl   06:18   0:12 /usr/lib64/firefox/firefox -contentproc -childID 23 -isForBrowser -prefsLen 7478 -prefMapSize 426224 -parentBuildID 20200811042452 -appdir /usr/lib64/firefox/browser 964 tab
pacjent     1721  0.8  1.5 2861332 242188 tty7   Sl   06:19   0:14 /usr/lib64/firefox/firefox -contentproc -childID 24 -isForBrowser -prefsLen 7478 -prefMapSize 426224 -parentBuildID 20200811042452 -appdir /usr/lib64/firefox/browser 964 tab
pacjent     2084  4.5  1.4 2790136 229852 tty7   Sl   06:36   0:37 /usr/lib64/firefox/firefox -contentproc -childID 25 -isForBrowser -prefsLen 7777 -prefMapSize 426224 -parentBuildID 20200811042452 -appdir /usr/lib64/firefox/browser 964 tab
pacjent     2782  0.0  0.5 2595616 80408 tty7    Sl   06:41   0:00 /usr/lib64/firefox/firefox -contentproc -childID 26 -isForBrowser -prefsLen 7934 -prefMapSize 426224 -parentBuildID 20200811042452 -appdir /usr/lib64/firefox/browser 964 tab

RTFM:

Kod: Zaznacz cały

man unshare

Pozdro

[enedil]

Jeżeli mechanizm Sandbox w Windows albo mechanizm Namespaces w Linuxie będzie miał błędy, to będzie wina Mozilli czy systemu operacyjnego?

Jeśli mechanizm sandboxujący gdziekolwiek będzie miał błędy, to będzie to wina twórcy takiego mechanizmu. Tutaj jednak ( https://googleprojectzero.blogspot.com/ ... 12388.html ) nie była to wina tego mechanizmu, a jedynie nieświadomego błędnego zastosowania. Takie błędy, gdzie żadna ze stron nie jest winna są ciężkie do wykrycia i przewidzenia. Ładna lista (od systemu, który od wielu lat *był* przemyślany pod kątem bezpieczeństwa):
https://flak.tedunangst.com/post/rethin ... d-security

[jacekalex]

@up

Microsoft i jego piaskownice?

Całą architektura Microsoftu stoi na głowie.
Potem zdarzają się takie "kwiatki"
https://www.cert.pl/news/single/krytycz ... 2020-1350/

I nie wypisuj bajek o błędach w których nikt nie zawinił, bo to bzdura.

Np u mnie Firefox jest ograniczony profilem AA, który to profil przyrządziłem osobiście.
I tak się nieszczęśliwe złożyło, że FF nie ma żadnej możliwości ingerowania w zawartość profilu AAA, który go chroni, programiści Mozilli też nie mają żadnego sposobu na ingerowanie w profil AA do Firefoxa, który mam w systemie.

Bezpieczeństwo systemu trzeba zlokalizować na poziomie kernela, a nie jak w Widnows, na poziomie poniżej kernela.
Do końca życia nie zapomnę opisu architektury Windows 7 w Haking 9, gdzie opisywali interfejs dla antywirusów, tzw mikrofiltry, a żeby lepiej wyjaśnić ich działanie objaśnili ich mechanizm na przykładzie exploita, który te mikrofiltry wyłącza w sposób niewidoczny dla antywirusa korzystającego z tych filtrów.
W najdroższych wersjach WIndows jest app-locker, a reszta musi sobie jakoś radzić.

Pozdro

[enedil]

I nie wypisuj bajek o błędach w których nikt nie zawinił, bo to bzdura.

To pisałem w znaczeniu "gdyby druga strona nie naskrobała, to przewinienia pierwszej nie prowadziłyby do eksploita".
A tak ogólnie, to w dalszym ciągu nie widzę jak niby błędy w przeglądarce mogą być w całości zmitygowane poprzez odpowiedni sandboxing (pomijając już kwestię tego co się dzieje na Windowsie).

[jacekalex]

3/4 błędów bezpieczeństwa w przegladarkach to skutek wtyczek takich jak flash czy java.
Np sławny Cryptlocker zaczął swoją karierę jako aplet javy.
Kllka innych malware też.

W tej chwili, jeśli kazda karta ma osobnego sandboxa, to co zostało do chronienia?
Baza zapamiętanych haseł, certyfikaty SSL, i co jeszcze?
Dostęp do plików na dysku reguluje sandbox i systemowy ACL, dostęp do flaków systemu operacyjnego reguluje sandbox i systemowy ACL.
Dostęp do historii przeglądarki i zapisanych ciasteczek też reguluje sandbox konkretnej karty.


W każdym razie 85% roboty z bezpieczeństwem albo wyparowało (pożegnanie wtyczek), albo da się zablokować wbudowanymi mechanizmami systemu operacyjnego, co jest dużo łatwiejsze, niż wpychanie baypasów zabezpieczających w kod przeglądarki.

W kontekście Linuxa radzę porównać jajo 2.6.20.16-generic z Ubuntu 7.04 z obecnym stabilnym kernelem 5.8.1
w moim systemie, zwłaszcza w kontekście Cgroup, Seccomp, Namespaces i Apparmor, czyli czterem mechanizmom, których obecnie używa FF i Chrome.
Pomijając same cechy kompilatora też mają conieco do powiedzenia w kontekście bezpieczeństwa:

Kod: Zaznacz cały

hardening-check /usr/lib64/firefox/firefox
/usr/lib64/firefox/firefox:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: yes
 Control flow integrity: unknown, no -fcf-protection instructions found!

Hardening na poziomie kompilatora ma zapewnić ochronę przed prawdziwymi exploitami.

Pozdro