B

ottleneck Bandwidth and RTT, czyli BBR jest nowym algorytmem kontroli przeciążenia TCP od firmy Google. Został on przetestowany w jego centrach danych, jak i frontowych serwerach takich stron jak: Google.com oraz YouTube.com. Dąży on do optymalizacji zarówno przepustowości, jak i opóźnienia – RTT. Jak wspomina samo Google po wprowadzeniu tego mechanizmu do swojej usługi publicznej chmury obliczeniowej, uzyskał średnio od 4% – 14% większą przepustowość sieciową. Pierwsze publiczne wydanie BBR nastąpiło we wrześniu 2016 roku. Do jego użycia wymagane jest posiadanie jądra w wersji 4.9 lub wyższej, w przeciwnym wypadku wymagane jest nałożenie łatki i rekompilacja jądra.
[ czytaj całość… ]

W

naszej serii o różnych, popularnych rozwiązaniach wśród środowisk DevOps mamy już Elasticsearch oraz Mesos/Marathon. Natomiast jeśli skupimy się stricte na ilości ujawnianych danych okazuje się, że prawdziwie miażdżącą siłą w tej kategorii jest Hadoop/HDFS. Nawet taki gigant, jak MongoDB nie jest mu w stanie dotrzymać kroku. Pod koniec maja tego roku na około (i tylko) 4500 instancjach rozproszonego systemu plików HDFS udostępnionych zostało blisko 5 PB danych. Najwięcej z nich znajduje się na terenie USA oraz Chin, gdzie za ich hosting odpowiedzialne są takie firmy, jak Amazon oraz Alibaba (obrazek #1 – mapa rozproszenia instalacji HDFS – źródło).
[ czytaj całość… ]

J

ak zostało to wspomniane we wcześniejszym wpisie – w wersji Linuksa v3.14 został wprowadzony mechanizm Kernel Address Space Layout Randomization. Wiele dystrybucji od jakiegoś czasu i tak zdecydowało o włączeniu KASLR dlatego od wersji v4.12 jądra Ingo Molnar podjął decyzję o jego aktywacji w standardowej konfiguracji. Oznacza to, że kod jądra będzie losowo umieszczany w pamięci RAM przy każdym starcie systemu:

# 1'wsze uruchomienie
root@darkstar:~# cat /proc/kallsyms | grep ' commit_creds\| prepare_kernel'
ffffffff8109eb60 T commit_creds
ffffffff8109ee40 T prepare_kernel_cred
# 2'gie uruchomienie
root@darkstar:~# cat /proc/kallsyms | grep ' commit_creds\| prepare_kernel'
ffffffffaa0a3bd0 T commit_creds
ffffffffaa0a3fc0 T prepare_kernel_cred

Na temat efektywności tego rozwiązania wypowiedział się Brad Spengler z PaX Team. Warto również zapoznać się z prezentacją Black Hat – „Breaking Kernel Address Space Layout Randomization (KASLR) With Intel TSX”. Dlatego rozwiązanie to należy traktować jako jedną z wielu warstw do ochrony systemu.

Więcej informacji: Kernel address space layout randomization

J

eśli zainstalujemy natywną paczkę MongoDB w dystrybucji Ubuntu 16.04 LTS w wersji 2.6.10 i po jej uruchomieniu przejdziemy do katalogu, gdzie są przechowywane metadane i bazy – wówczas prawa dostępu do plików i katalogów będą wyglądać tak. Niestety jeśli podążymy drogą oficjalnej instrukcji instalacji dla wersji 3.4 (tutaj 3.4.6) to już prawa dostępu będą wyglądać tak. Od razu widać, że uprawnienia te są zbyt szerokie i każdy użytkownik posiadający konto na serwerze jest w stanie wykonać pełną kopie wszystkich danych z tego katalogu (np. za pomocą programu tar). Okazuje się, że błąd ten jest znany od 2015 roku. Stanowić to może poważny problem bezpieczeństwa dla hostingu oraz usług współdzielonych oferujących tego typu bazę. Każdy użytkownik jest w stanie pozyskać dane „sąsiadów” i nie musi nawet posiadać konta z aktywną powłoką – zawsze może uruchomić zadanie cron, które skopiuje mu dane do jego katalogu przewidzianego dla strony www, później pobierając je przy pomocy HTTP, czy FTP. Rozwiązaniem tego błędu jest przywrócenie poprawnych praw dostępu do katalogu /var/lib/mongodb:

chmod o-rx /var/lib/mongodb

oraz modyfikacji umask dla użytkownika mongodb.

Więcej informacji: MongoDB at shared hosting: security surprises

L

uka została ujawniona podczas zgłoszenia błędu na githubie. systemd nie potrafi obsłużyć odpalenia procesu użytkownika, którego login zaczyna się od liczby np. 0day i tym samym uruchamia proces z prawami administratora zamiast owego użytkownika. Brzmi to dość drastycznie:

> In case of bug report: Expected behaviour you didn’t see
The process started by systemd should be user previlege

> In case of bug report: Unexpected behaviour you saw
The process started by systemd was root previlege

[ czytaj całość… ]

Co nie pasuje w poniższym listingu?

root@darkstar:~/bmap-1.0.20# ls -al
total 488
drwxr-xr-x  6 root root  4096 Jul  4 20:52 .
drwx------ 22 root root  4096 Jul  4 20:46 ..
drwxr-xr-x  2 root root  4096 Jul  4 20:52 ..
-rwxr-xr-x  1 root root 46996 Jul  4 20:47 bclump
-rw-r--r--  1 root root 10364 May 30  2000 bclump.c
-rw-r--r--  1 root root     0 Jul  4 20:48 bclump-invoke.sgml
-rw-r--r--  1 root root 17592 Jul  4 20:47 bclump.o
-rwxr-xr-x  1 root root 61130 Jul  4 20:46 bmap
-rw-r--r--  1 root root 13030 May 15  2000 bmap.c
-rw-r--r--  1 root root     0 Jul  4 20:48 bmap-invoke.sgml
-rw-r--r--  1 root root 27264 Jul  4 20:46 bmap.o
-rw-r--r--  1 root root 12811 May 30  2000 bmap.sgml.m4
-rw-r--r--  1 root root   824 May 15  2000 bmap.spec
-rw-r--r--  1 root root   266 Jul  4 20:46 config.h

[ czytaj całość… ]

K

rytyczna podatność została odkryta w ulubionym monolicie inita świata linuksowego – systemd. Pozwala ona na potencjalne wywołanie przepełnienia bufora oraz uruchomienie szkodliwego kodu na atakowanej maszynie, a to wszystko za pomocą odpowiedzi DNS. CVE-2017-9445 aktualnie rezyduje w funkcji dns_packet_new komponentu systemd-resolved służącego do obsługi odpowiedzi DNS, który zapewnia rozwiązywanie nazw DNS dla innych daemonów i aplikacji sieciowych. Według oficjalnego ostrzeżenia opublikowanego we wtorek specjalnie spreparowana odpowiedź od wrogiego serwera DNS może spowodować awarię programu ‚systemd-resolved’. Wysłanie bardzo dużej odpowiedzi DNS może doprowadzić do przepełnienia buforu umożliwiając atakującemu nadpisanie pamięci prowadząc do zdalnego wykonania kodu. Oznacza to, że napastnicy mogą zdalnie uruchomić złośliwe oprogramowanie na docelowym serwerze za pośrednictwem wrogiej usługi DNS. Luka ta występuje od wersji 223, która pojawiła się w czerwcu 2015 roku i jest obecna we wszystkich wersjach do 233 wydanej w marcu tego roku. Oczywiście systemd-resolve musi być uruchomiony w systemie, aby stanowił dla niego zagrożenie. Błąd dotyka takie dystrybucje jak: Ubuntu 16.10 oraz 17.04; Debian Stretch (9), Buster (10) i Sid (wersja niestabilna) oraz inne używające systemd.

Zobacz również: systemd v228, screen root exploit i globalne problemy z setuid

Publikacja jest bardzo dobrą ilustracją „crime industry” obserwowanego na przykładzie forów Polish Board & Market (PBM), ToRepublic, a także Polskiej Ukrytej Wiki (PUW). Autor nie ogranicza się wyłącznie do przedstawienia i skomentowania wybranych treści, ale przede wszystkim stara się dokonać analizy skutków prawnych grożących ich twórcom i użytkownikom. Formułuje interesującą koncepcję grupy cyberprzestępczej złożonej z rdzenia (core criminal group) oraz reszty wierzącej w swój indywidualny charakter udziału (organised criminal network), wraz z jej czteropoziomową strukturą. Swoje rozważania prawne dotyczące udziału w zorganizowanej grupie lub związku przestępczym, podżegania, pomocnictwa i publicznego nawoływania do popełnienia przestępstwa opiera na bogatej literaturze i przykładach z polskojęzycznego darknetu oraz orzecznictwa amerykańskiego.

– z recenzji dr hab. inż. Jerzego Kosińskiego, prof. WSPol
[ czytaj całość… ]

Czym jest Stack Clash? Jest to eksploatacja błędu w zarządzaniu pamięci oparta na dość starej (12 letniej) technice. Dotyka ona kilku systemów operacyjnych: Linuksa, OpenBSD, NetBSD, FreeBSD oraz Solarisa dla architektury i386 oraz amd64. Technika ta może zostać wykorzystana przez atakujących do naruszenia bezpieczeństwa pamięci oraz wykonania dowolnego kodu. Polega ona na pewnej zależności: każdy program uruchomiony na komputerze używa specjalnego obszaru pamięci zwanego stosem (ang. stack). Obszar tej pamięci jest szczególny, ponieważ rośnie automatycznie wraz z zapotrzebowaniem na niego przez program. Jeśli jednak przyrost jest zbyt duży i zbliży się do innego obszaru pamięci (na przykład sterty – ang. heap) może dojść do sytuacji, w której program może pomylić stos z innym obszarem pamięci. Daje to możliwość wykorzystania owego zamieszania do nadpisania stosu przez inny obszary pamięci lub odwrotnie.
[ czytaj całość… ]

J

eśli jesteśmy szczęśliwymi właścicielami dedykowanego lub prywatnego serwera na własne potrzeby – ze względu na bezpieczeństwo (zapasowe źródło zdarzeń, jakie zaszły na serwerze w przypadku incydentu bezpieczeństwa) oraz możliwości dynamicznej analizy danych – warto pomyśleć nad wysyłaniem wszystkich logów systemowych oraz aktywności dedykowanych aplikacji do dodatkowego, zdalnego źródła. Oczywiście nie mowa tutaj o drugim serwerze, z którym wiążą się dodatkowe koszty utrzymania, ale serwisach, które za darmo umożliwią nam taki proces:

• papertail – przechowywanie: 7 dni wstecz; ilość: 100MB/miesiąc; okno wyszukiwania: 48 godzin.
• logentries – przechowywanie: 7 dni wstecz; ilość: 5GB/miesiąc; okno wyszukiwania: 7 dni.
• loggly – przechowywanie: 7 dni wstecz; ilość: 200MB/dzień; okno wyszukiwania: 7 dni.
• sematext – przechowywanie: 7 dni wstecz; ilość: 500MB/dzień; okno wyszukiwania: 7 dni.
• sumologic – przechowywanie: 7 dni wstecz; ilość: 500MB/dzień; okno wyszukiwania: 7 dni.
• logz – przechowywanie: 3 dni wstecz; ilość: 1GB/dzień; okno wyszukiwania: 3 dni.
• xpolog – przechowywanie: 5 dni wstecz; ilość: 1GB/dzień; okno wyszukiwania: 5 dni.

Jedyną wadą tego rozwiązania jest krótki czas retencji zdalnego archiwum, ale zakładam, że raczej nikt nie przewiduje dłuższego czasu wykrycia / zauważenia anomalii w działaniu swojego serwera niż kilka godzin.