N

ajnowsza wersja Linuksa otrzymała nową funkcję bezpieczeństwa o nazwie „LoadPin”, która została przeniesiona z systemu Chrome OS i umożliwia wprowadzenie ograniczeń odnośnie nośników i lokalizacji, z których mogą być ładowane moduły i firmware jądra. Innymi słowy LoadPin jest nowym mini Modułem Bezpieczeństwa Linuksa (ang. Linux Security Module – LSM, który przechwytuje skonsolidowany zaczep LSM wywołania kernel_file_read, aby nasz system ładował wszystkie dodatki (moduły, firmware, obrazy kexec, polityki bezpieczeństwa) pochodzące z jednego zaufanego systemu plików. Poprzez zaufany system plików rozumie się tutaj taki, który jest umieszczony na urządzeniu tylko tylko-do-odczytu (np. CDROM lub dm-verity [wbudowany w Androidowe jądro od czasów wersji 4.4]). Niweluje to konieczność podpisywania każdego ładowanego pliku z osobna, ponieważ pierwszy plik ładowany przez interfejs odczytu plików jądra jest „przypinany” do systemu plików użytego do załadowania, a wszystkie pliki pochodzące z poza niego są odrzucane. Włączeniem lub wyłączeniem funkcji możemy sterować poprzez opcję SECURITY_LOADPIN_ENABLED w jądrze lub parametrem loadpin.enabled=1/0 przy starcie systemu.

Więcej informacji: The LoadPin security module

Nigdy, przenigdy nie ładujemy sesji screen / tmux na użytkowniku, który później w tej samej sesji odpala polecenie sudo / su i zostawia zawieszoną sesję (Ctrl + A + D) z uprawnieniami użytkownika root. Po przejęciu takiego konta – uzyskanie kontroli nad całym systemem ogranicza się wtedy do polecenia: screen -r. Scenariusz zawsze powinien być następujący: logowanie na zwykłego użytkownika ›› sudo su ›› screen ›› zawieszenie sesji i wylogowanie się z root.

W

większości przypadków systemy Linuksowe dobrze radzą sobie z obsługą pamięci. Istnieje zawsze ryzyko, że niektóre programy wymkną się spod kontroli i przydzielą sobie więcej pamięci niż jest normalnie możliwe i wejdą w strefę pliku wymiany. W takich sytuacjach można zaobserwować znaczne spowolnienie systemu (chyba, że używamy dysków SSD dla swap), a sprawdzenie dostępnej pamięci będzie prawdopodobnie pierwszą rzeczą jakiej należy się przyjrzeć.
[ czytaj całość… ]

P

oważna podatność została wykryta, a raczej powróciła po 15 latach (pierwsze błędy tego typu zostały odkryte i naprawione w bibliotece Perla w marcu oraz Curla w kwietniu 2001 roku). Głównie dotyka aplikacje oraz serwery działające z interfejsami CGI lub podobnymi. Wszystko sprowadza się do prostego konfliktu w nazwach zmiennych. Według RFC 3875 aplikacja CGI pobiera wartość nagłówka HTTP o nazwie Proxy (który może zostać wysłany w dowolnym żądaniu użytkownika) i zapisuje ją pod zmienną środowiskową HTTP_PROXY. Problem w tym, że ta zmienna środowiskowa jest używana do konfiguracji serwera proxy przy łączeniu się aplikacji i serwerów WWW z Internetem.
[ czytaj całość… ]

K

olejny atak na jedno z narzędzi Linuksowych. Tym razem ofiarą mogą paść użytkownicy korzystający z programu wget do ściągania różnych plików z niezaufanych źródeł. Podatność polega na wykorzystaniu sposobu w jaki narzędzie to radzi sobie z przekierowaniami. Atakujący, który kontroluje serwer lub jest w stanie przechwycić sesję użytkownika może spowodować wykonanie dowolnego polecenia po stronie klienta.
[ czytaj całość… ]

J

eśli używamy do połączeń IPv6 z niektórych lokalizacji / serwerów możemy napotkać problemy z łącznością do security.ubuntu.com w trakcie polecenia apt-get update. Jest to znany błąd, a jego tymczasowym rozwiązaniem jest skonfigurowanie pierwszeństwa dla połączeń IPv4 przed IPv6 poprzez odkomentowanie wpisu w pliku /etc/gai.conf:

#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

Więcej informacji: Prefer A (IPv4) DNS lookups before AAAA(IPv6) lookups

Z

acznijmy od początku. Społecznościówki (Google+, Facebook, LinkedIn), e-banki, e-płatności, e-commerce, hotele itp. – wszystkie wymagają podania adresu e-mail. Do prawie wszystkich można zalogować się w klasycznym układzie typu: e-mail / hasło. Nie trzeba już wymyślać sobie kozackiego, jedynego nicku, ponieważ serwisy zaczynają traktować adresy e-mail jako unikatowe identyfikatory użytkowników z którymi w ten sposób mogą prowadzić „bezpieczną” komunikację. Wszechobecne dzielenie się adresem e-mail z technicznego punktu widzenia nie jest złe, ale na dłuższą metę powoduje kilka irytujących problemów – spam, poznanie Twojego loginu do poczty przy wycieku danych itd. Niektóre z nich można rozwiązać lub uczynić znacznie prostszymi za pomocą aliasów pocztowych.
[ czytaj całość… ]

F

acebook będzie teraz wyświetlał reklamy nawet użytkownikom, którzy nie są zarejestrowani w jego sieci społecznościowej. Może by tak zablokować ich całą sieć? Jak to zrobić najprościej? Wystarczy znaleźć system autonomiczny danej firmy i wyciągnąć z niego całe bloki sieci, które można dodać do reguł blokujących na ścianie ogniowej.
[ czytaj całość… ]

W

rozwoju oprogramowania termin time of check to time of use (TOCTTOU lub TOCTOU) jest klasą błędów typu race conditions spowodowanych zmianami w systemie, które występują pomiędzy czynnościami: sprawdzeniem warunku (np. poświadczeniem bezpieczeństwa), a wykorzystaniem wyników tego sprawdzenia. Przykład: wyobraźmy sobie aplikację webową, która pozwala użytkownikom na edycję wybranych stron oraz administratorom na blokowanie takich modyfikacji. Użytkownik wysyła żądanie do aplikacji o edycję strony i otrzymuje formularz umożliwiający mu przeprowadzenie tej operacji. Po edycji treści, ale przed wysłaniem formularza do aplikacji przez użytkownika – administrator blokuje stronę, co powinno zapobiec jej edycji. Ze względu na fakt, że proces edycji już się zaczął, gdy użytkownik wyślę zawartość formularza (razem z zmienioną treścią) to zostanie ona zaakceptowania. Dlaczego? Gdy użytkownik rozpoczął edycję aplikacja sprawdziła jego uprawnienia i rzeczywiście mógł edytować stronę. Zezwolenie zostało cofnięte później, już po sprawdzeniu autoryzacji dlatego modyfikacje zostały dopuszczone.
[ czytaj całość… ]

P

rzeglądarki Chrome oraz Chromium wraz z wydaniem wersji 51 przestały wspierać rozszerzenie protokołu TLS – NPN, który pozwalał na negocjację połączeń za pomocą protokołu SPDY i HTTP/2 z klientami. Mechanizm ten został zastąpiony ALPN. Dobrą decyzją jest przełączenie się z NPN na ALPN, ponieważ wiąże się z tym więcej korzyści niż strat, ale całkowite porzucenie NPN już decyzją dobrą nie jest.
[ czytaj całość… ]