UnrealIRCd.com: dystrybucja zainfekowanego programu dla Linuksa
- Dodano: 13 czerwca 2010
- Wprowadził: hcsl.pl
- Komentarze: 68
Użytkownicy systemów operacyjnych z rodziny Linux (obok użytkowników systemu OS X) bardzo często wyrażają pogląd, że ich system jest praktycznie zupełnie odporny na wszelkiego rodzaju infekcje oraz zagrożenia ze strony złośliwego oprogramowania. W jak dużym są jednak błędzie, świetnie obrazuje ostatni przypadek zainfekowanych kodów źródłowych dystrybuowanych przez UnrealIRCd.com.
Administratorzy serwisu UnrealIRCd.com przyznali wczoraj, że dystrybuowane za pośrednictwem niektórych lustrzanych serwerów oprogramowanie Unreal 3.2.8.1 zawierało złośliwy kod (trojana Troj/UnIRC-A). Oficjalne, skompilowane wersje dla systemu Windows oraz źródła w CVS nie zostały podmienione. Jednakże, wygląda na to, że już w listopadzie ubiegłego roku intruzom udało się podmienić plik Unreal3.2.8.1.tar.gz zawierający kod źródłowy programy na własny zbiór. Co najciekawsze, przez około pół roku włamanie nie zostało przez nikogo zauważone.
Zadanie intruzom ułatwili sami administratorzy projektu, którzy niewystarczająco zadbali o bezpieczeństwo. Przede wszystkim zawartość repozytorium nie była w żaden sposób monitorowana. Po drugie, nie publikowano sum kontrolnych plików. Wreszcie po trzecie, serwery lustrzane również w żaden sposób nie sprawdzały sum kontrolnych, pobierając i rozpowszechniając tym samym automatycznie zainfekowane zbiory. Incydent skłonił administratorów do wdrożenie podpisów cyfrowych (GPG), co powinno uchronić użytkowników przed tego typu atakami w przyszłości.
Mamy więc do czynienia z kolejnym przypadkiem (wystarczy tylko wspomnieć Black-Horse Trojan dla Linuksa) świadczącym o tym, że użytkownicy oraz administratorzy systemów z rodziny Linux nie powinni ulegać schematycznemu myśleniu i zawsze powinni brać pod uwagę możliwość wprowadzenia złośliwego kodu do własnych systemów.
Więcej informacji: http://www.hcsl.pl/2010/06/wprowadzenie-...snego.html
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.
68 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
I to wina linuxa? Chyba nie… co za dzieciak stawiał to repo…
Nie chodzi o "repo" takie jak znasz z Ubuntu. Kod źródłowy oprogramowania został zainfekowany na serwerze twórcy, a stamtąd trafił do mirrorów. Z mirrorów pobrali to twórcy różnych dystrybucji, skompilowali, popaczkowali i wrzucili co repozytoriów swoich dystrybucji (np. Ubuntu czy Archa). Z tych ostatnich repozytoriów pobrali to użytkownicy i administratorzy. Więc uważaj kogo nazywasz dzieciakami, dzieciaku
.
I po drugie: tak; w pewnym sensie jest to wina "Linuksa". To chyba nie jest pierwszy raz kiedy taki atak był wykonany. Oprogramowanie w Linuksowym świecie zawsze było rozprowadzane w ten, "podatny" na infekcję sposób: <code>autor -> strona autora -> twórca dystrybucji -> repo -> użytkownik</code>. Zabezpieczony i sprawdzany jest zazwyczaj ostatni odcinek, <code>repo -> użytkownik</code>. Odcinek <code>strona autora -> twórca dystrybucji</code> może być sprawdzany, ale wcale nie musi. Sprawa wygląda jeszcze gorzej, jeśli sam administrator pobiera oprogramowanie z strony autora – ktoś z Was kiedyś sprawdzał po pobraniu *.tar.gz z źródłami coś więcej, niż sumy md5? Sumy md5 pobrane z tej samej, być może zainfekowanej strony
?
I na dodatek tutaj wykrycie infekcji zajęło pół roku!
@hiciu:
Dalej nie rozumiem dlaczego to wina Linuksa? Trojan to nie infekcja, nie zainfekował Linuksa, tylko został na nim zainstalowany przez użytkownika, samodzielnie trojan się na nim nie instalował!
I wyjaśnij mi, w jaki sposób, choćby hipotetyczny, system operacyjny (dowolnego rodzaju) ma się chronić przed instalacją trojana dołączonego do instalowanego przez użytkownika softu? Przecież to rola użytkownika, a nie OS! To użytkownik ma sprawdzać co instaluje…
I może rozwiniesz wątek dlaczego niby linuksowy sposób dystrybucji oprogramowania jest większym zagrożeniem niż windowsowy? W Linuksie przynajmniej hipotetycznie mogę sprawdzić kod źródłowy, a w Windows nawet hipotetycznie nie! Czy mało było przypadków dołączania spyware do windowsowego oprogramowania i to celowo przez twórców oprogramowania? Czy sam mechanizm aktualizacji Windows jest bezpieczny? Sprawdzasz kody źródłowe aktualizacji dostarczanych przez Microsoft? Nie, bo to "poważna" firma? Oracle też jest poważną firmą, a jednak był co najmniej jeden przypadek udowodnienia jej umieszczenia backdoor'a w jej bazie i znając amerykańskie prawo, wątpię by ich produkty były pozbawione czegoś takiego teraz… Najpopularniejsze w USA oprogramowanie podatkowe też okazało się ma "feature" polegający na "mechanizmie odzyskiwania on line danych, gdy użytkownik zapomni swojego hasła" (OK, tylko czemu firma nie reklamowała tego "feature" w opisie programu, a ujawniła tą zaletę dopiero po tym, jak opisali ją hackerzy?…).
Muszę nadmienić, że problemem nie był linuksowy sposób instalacji oprogramowania, lecz windowsowy(szukanie programu po stronkach, pobieranie, instalacja) w wydaniu linuksowym. Linux po prostu nie jest przygotowany na to, że ktoś będzie instalować programy ze stronki, gdyż jest to zwyczajnie zbędne.
O rany, tak trudno sobie wyobrazic sprytniejszy atak? Zaloz, ze distro do repo dodalo jakies malware.
System powinien w maksymalnym stopniu chronic usera przez zagrozeniami. Jesli zostalo zainstalowane malware to powinno maksymalnie skasowac samo siebie. Ale czego wymagac, kiedy w wielu distrach wszystko laduje do jednego wora (chodzi o sama lokalizacje plikow).
Zeby bylo jasne — wkurza mnie hipokryzja. Jak jest atak na windows, uuu, jaki ten windows cieniutki, jak jest atak na Linuxa, no tak, Linux super, ale user zawiodl. Jasne, swieta krowa nie podlega krytyce.
@macias: Problemem jest "co to jest system". Gdyby była dziura w Adobe Flash dla Windows to nie powiedziałbym że Windows jest dziurawy tylko Flash i ewentualnie user zawinił (albo i nie).
Wymieniony program zresztą jest międzyplatformowy więc jeśli Linux jest dziurawy to i Windows jest dziurawy (bo w żaden sposób nie można powiedzieć że to program 'systemowy') – zgoda co innego np. glibc czy kernel wtedy (GNU/)Linux *byłby* dziurawy.
Chodzi mi o to, ze domyslnie distra Linuxa nie maja zadnych zabezpieczen przed malwarem. Tymczasem kazdy program powinien miec wlasny sandbox i kazdy z nich zeby wyjsc na zewnatrz powinien prosic o zgode usera.
Zobacz np. rpma i suse. Czy sa ograniczenia (domyslnie) co do pre i post instalacji? Nie. Jak juz raz instalacja sie rozpocznie moze zostac skasowany caly system w fazie pre instalki.
Takie sandboxy istnieją – choćby Gentoo instaluje przez sandbox (uwaga – chroni to przed make install a nie złośliwym ebuildem. Nie wiem czy jest 100% bezpieczne – celem było chronienie przed pomyłkami a nie celowym obejściem). Również – patrz SELinux. Powód ich niestosowania – praktyka. Szczególnie programy użytkownika.
Z tego co rozumiem pre- i post- instalacje to chodzi o skonfigurowanie tego co nie jest automatyczne (rebuild indexu dokumentacji etc.) więc domyślne ograniczenia byłyby trochę 'denerwujące' gdyż te skrypty mają właśnie obsługiwać to czego nie da się załatwić wprost rozpakowaniem[1].
Co do sandboxu dla aplikacji użyszkodnika:
"Czy chcesz zapisać plik?" Tak
"Program emacs prosi o pozwolenie zapisania pliku …" Tak
"Zapisz stone jako?"
"Program firefox-bin prosi o pozwolenie zapisu do katalogu Desktop/Downloads." Ta
….
"Program malware1234 prosi o pozwolenie zapisania pliku .bashrc?" Tak (wpisane bez myslenia)
[1] Zgoda – nie tak często się instaluje więc i może nie byłoby to tak złe ale nie wyobrażam sobie wprowadzenia czegoś takiego w dysytrybucji dla ZU.
imho nie ma pakietu Unreal w repo ubuntu (8.10 tls) oraz debiana
Nie prawda. Twórca dystrybucji pomija stronę autora, bo od razu wszystko pobiera z SVN/GIT/itd. Oznacza to, że repozytoria dystrybucji nie były zainfekowane. Linuksy też(szczęście w pechu) nie mogły zostać zainfekowane, gdyż instalacja z wersji dostarczanej na stronach autorów wymagała kompilacji. Skoro i tak trzeba skompilować, to więszkość ludzi pobierze od razu z systemu kontroli wersji. Jedynie skompilowane wersje na Windows stanowiły spore zagrożenie, a wersji na Linuksa nikt by nie instalował z tej strony.
Jeżeli strona jest zainfekowana, to sumy md5 też mogły zostać podmienione. Dlatego nie instaluje się oprogramowania ze stronek, lecz z repo lub systemów kontroli wersji, które są niepodatne na zagrożenia. Twórcy dystrybucji też o tym wiedzą, więc pobierając wszystko z SVN czynią, że repo nie będzie skażone.
a co z md5, czy nie wystarczy że będzie się go sprawdzać ??
Nie chodziło mi w żadnym razie o piętnowanie Linuksa, lecz o wskazanie kolejnego przykładu na to, że wprowadzenie złośliwego kodu do swojego Linuksa wcale nie jest takie strasznie trudne.
jeden z najgorszych tekstow jakie tu widzialem.
zrodla daemona ircd zostaly skompromitowane – a nie linux, czy mac osx.
tak dalekie analogie mogl pociagnac jedynie leszcz nie majacy pojecia o strukturze jakiegokolwiek systemu uniksoidalnego…
jak dodac "wyniosly sposob pisania" razaco smieszacy (nie pierwszy raz) – a do tego "hard core security labs" (ciekaw jestem co w tym laboratorium bylo samodzielnie przebadane
) – to sam nie wiem czy smiac sie czy plakac nad poziomem wrzucanych tu tekstow…
a gdzie to widzisz, żebym napisał, że to Linux czym OS X był źródłem problemów?
ciekaw jestem co w tym laboratorium było samodzielnie przebadane?
pierwszy akapit sugeruje ze problem moze byc powiazany z zagadnieniami zabezpieczen systemow uniksoidalnych.
caly ten aktapit (podobnie jak doklejony "od czapy" ostatni) to jeden wielki belkot nadetym jezykiem pisany (tzw. pseudospecjalistycznym).
Pierwszy akapit niczego nie sugeruje, tylko mówi o tym, że do własnego Linuksa można wraz z zainfekowanym programem wprowadzić stosunkowo łatwo złośliwy kod i zawsze warto o tym pamiętać.
@Jellonek, czytasz wlasne imaginacje. Tak to jest na ogol, jak koniecznie ktos sie chce wykazac jaki on profesjonalny i czegos sie czepic.
To ja tez — uklad przecinkow sugeruje, ze tekst jest sponsorowany przez IBM.
Mam rozumieć, że taki serwer mógł zostać uruchomiony bez praw root-a? Zresztą, to nawet Apache działa we współczenych dystrybucjach na użytkowniku www/httpd lub apache. Jeżeli ktoś, przyzwyczajony z Windows, instaluje programy w ten sposób(przez jakiś instalator), to się nie dziwię(piszę o wersji pod Windows). Instalacja z kodów źródłowych nadal pozwala na uruchomianie serwera na innym użytkowniku, niż root.
No to będzie rozsyłał spam z użytkownika "ircd", co za różnica?
A i "co chwilę" pojawia się dziura pozwalająca każdemu użytkownikowi stać się rootem…
Noo.. teoretycznie tak. Prawa roota nie są potrzebne do otwarcia portu i uruchomienia serwera irc na nim. Chyba źle do tego podchodzisz
.
Jest mnóstwo sposobów na zdobycie praw roota w takim przypadku. Na przykład: <code>make install</code> w pewnym momencie zawsze wykonuje się z prawami roota. Jeśli to Cię nie przekonuje, to np. właścicielem prawie wszystkich binarkek w /usr/bin/* jest root – wystarczy zrobić <code>chmod +s</code> w pewnym momencie (a możemy to zrobić, bo zainfekowaliśmy np. Makefile).
Nieprawda. Apache domyślnie nasłuchuje na porcie 80 – do tego są mu potrzebne prawa roota (lub CAP_NET_BIND_SERVICE pod Linuksem) a dopiero potem robi <code>setuid()</code> na www/httpd/apache. Skrypt startowy odpalasz z prawami roota, skrypt wykonuje <code>/usr/sbin/apache2ctl start</code> i już – zainfekowany kod został wykonany z prawami roota
.
No i jak Groszek zauważył, prawa roota wcale nie są potrzebne żeby rozsyłać spam, uruchomić i udostępnić na zewnątrz <code>/bin/bash</code>, czytać pliki z <code>r–r–r–</code> w Twoim home czy robić dużo innych złych rzeczy.
"Nieprawda. Apache domyślnie nasłuchuje na porcie 80 – do tego są mu potrzebne prawa roota"
i
"Noo.. teoretycznie tak. Prawa roota nie są potrzebne do otwarcia portu i uruchomienia serwera irc na nim. Chyba źle do tego podchodzisz"
Apache też mógłby nasłuchiwać na innym porcie, więc prawa root-a nie byłyby mu potrzebne.
"Jest mnóstwo sposobów na zdobycie praw roota w takim przypadku. Na przykład: make install w pewnym momencie zawsze wykonuje się z prawami roota."
Nie prawda. Jeżeli w configu ustawię odpowiedni prefiks, to nie będzie wymagać praw root-a.
"Jeśli to Cię nie przekonuje, to np. właścicielem prawie wszystkich binarkek w /usr/bin/* jest root"
No i co z tego?
CAP_NET_BIND_SERVICE – i to wystarcza. Z podobnego rozwiązania korzysta np. program ping.
Niedokońca. Oczywiście poza dystrybucjami 'źródłowymi' mało kto tak robi ale istnieje sandboxing+userpriv. Zgoda – nadal niedoskonały etc. ale podwyższa poziom trudności. Dodatkowo pomijając ustawienia CAP etc. nie musi być on wykonywany z prawami roota – bo do /usr i tak nie pisze
W skrócie – make install nie pisze gdzie popadanie tylko instaluje do DISTDIRa (jeśli spróbuje pisać gdzieś indziej to jest abort przed otwarciem pliku). Potem instalator sprawdza czy nie ma konfliktów i przenosi pliki (ew. wykonuje przedtym jakieś dodatkowe akcje typu strip).
W skrócie – nie zawsze jest tak prosto.
PS. W ostateczności jest jeszcze SELinux czy podobne wynalazki.
facepalm…. repo bez sum kontrolnych?
Skoro ktoś podmienił źródła, to mógł podmienić również sumy, prawda
? Chodziło Ci o podpisanie źródeł przez np. pgp. Ale tutaj też jest pułapka – żeby sprawdzić taki podpis musisz mieć klucz publiczny autora.. A ten możesz pobrać z strony autora, na której mógł zostać podmieniony tak samo jak źródła i sumy (tak, wiem – klucze pobiera się z keyserverów).
to zależy … zwykle sumy leżą w zupełnie innym miejscu. ale to zależy od polityki.
Według mnie jest jest to wina linuksa (nie ma to związku z żadnym systemem operacyjnym).
Centralne repo jest stosowane w dużo większej ilości systemów. Cz to jest ogólnie dostępne linux/freebsda/macporty czy zamkniete implemetacje jak markety/story mobilne.
To że panowie X znaleźli tego trojana po pół roku nie znaczy że od pół roku zainfekowany kod był w dystrach. Zwykle podmiana kodu nie jest taka banalna (no chyba że wydajemy wersje poprawkową podszywając się pod autora) gdyż większośc dystr liczy kilka sum kontrolnych różnymi algorytmami(kolizje md5 dosyc łatwo wygenerowac jednak aby sie wstrzelic dodatkow w sha czy inny algorytm to juz tak prosto nie jest). Sumy są przechowywane po stronie serwera dystrybucyjnego więc podmiana kodu jest nieskuteczna. Powoduje że po ściągnięciu kodu stwierdzamy że kod jest uszkodzony i sciągamy go kolejny raz z innego serwera aż trafiamy na kod którego suma jest poprawna.
Więc winą za znależienie się takiego kodu można obarcza poszczególnych paczkerówkolejnych distr.
sumy leżą w wielu serwisach, stąd podmiana nawet na stronie twórców już wzbudza podejżenia innych
W sumie to i dobrze się stało… Nic poważnego, ale trochę ludziom otworzy oczy i uświadomi, że czujnym trzeba być!
eee autor troche przesadził…
Normalną rzeczą jest że najsłabszym ogniwem jest użytkownik…
Tutaj w grę wszedł jeszcze marny administrator + zerowy poziom zabezpieczeń…
System można zniszczyć w 2 minuty jeśli ma się dostęp do roota, jeśli ktoś umyślnie instalował programy niewiadomego pochodzenia niech się liczy z ryzykiem.
Nie zwalajmy winy na system a na użytkownika…
Strona domowa projektu to "niewiadome pochodzenie" programu?
Strona domowa projektu jest tak samo wiarygodna jak jej twórcy. Znacz twórców? Ręczysz za nich głową?
Znasz RedHata osobiscie? Reczysz za nich glowa?
Reka w gore, kto przeanalizowal wszystkie zrodla uzywanych programow lacznie z zamknietymi driverami do kart graficznych.
Jesli dla ciebie RedHat jest tak samo malo wiarygodny jak tworcy tego programu, to gratuluje wyobrazni.
Słusznie zawsze trzeba być świadomym zagrożeń. Na szczęście taki przypadek to małe miki w porównaniu z tym co mają na co dzień użytkownicy pewnego popularnego systemu dla szklarzy czy jakoś tak. To jak informacja o nieszczęśliwym wypadku na strzelnicy pod Bonn w porównaniu z doniesieniami o kolejnej regularnej rzezi w Kongo.
Te "małe miki" po prostu odpowiada znaczeniu Linuksa na desktopach. Więcej użytkowników – więcej problemów.
No tak będzie więcej gości na strzelnicy pod Bonn to pewno taki wypadek zdarzy się znów. Tymczasem do afryki płyną kolejne kontenery z kałachami bo maczety się już stępiły…
licho nie spi – miej logi i patrzaj w logi
Mam jedno pytanie. Skąd wzięto informacje, że repozytorium jakiekolwiek distra posiadało zainfekowany program? Autor coś takiego sugeruje w niejednym komentarzu, a tymczasem u źródla, jak i gdziekolwiek indziej nie sporzeć, to brak o tym informacji. Byłoby to głupotą. Przecież kto ściąga źródła ze stronek, zamiast z SVN-u?
Wygląda na to, że tylko kilka dist paczkowało UnrealIRCd.
Znalazłem go w repo Gentoo i Archa; Debian ani Ubuntu nie paczkują UnrealIRCd.
Niestety i Gentoo, i Arch miały w swoich repozytoriach zainfekowaną wersję. Można to sprawdzić w Gentoo Bug 323691, oraz w changelogach Archa
Najwyraźniej "zainfekowany" był jeden z plików nagłówkowych (do jednego z makr dodano wywołanie systemowe – https://bugs.gentoo.org/show_bug.cgi?id=323691#c3….
Gentoo i Arch poprawiły sumy kontrolne w swoich repozytoriach. Gentoo usunęło też zainfekowanego tarballa z głównego mirrora.
Pytanie – kto powinien odpowiadać za zapobieganie takim sytuacjom (oczywiście oprócz administratorów zainfekowanego mirrora UnrealIRCd)? Wydaje mi się, że teoretycznie opiekunowie pakietów poszczególnych distr – np. opiekunowie pakietów Debiana powinni sprawdzać zmiany wprowadzone przez twórców (upstream changes) (por. Debian New Maintainers' Guide, Ch. 9.2 – "You then inspect changes between the old and new upstream sources as follow to watch out for anything suspicious").
W praktyce jednak każdy programista wie że łatwo zaszyć gdzieś jednolinijkową zmianę (zwłaszcza jeżeli w tym samym czasie jest wprowadzanych wiele innych zmian).
Podejrzewam że opiekunowie pakietów i tak przeglądają zmiany głównie pod kątem zgodności z własną dystrybucją, więc taka rzecz może umknąć.
Nie rozumiem natomiast co w końcu było w sumami kontrolnymi tarballa – bo po tym w końcu się ludzie z Gentoo zorientowali – dlaczego nie zostały sprawdzone wcześniej? I czy w końcu maintainerzy z distr paczkujących UnrealIRCd byli świadomi, że nastąpiła zmiana w źródłach (którą mogli uważać za "legalną" zmianę), czy też nie?
PS. Binarka windowsowa nie została podobno zainfekowana (zgodnie z oświadczeniem na stronie unrealircd.com). Pewnie dlatego, że binarkę przygotowują sami twórcy, a zainfekowane źródła były na jednym z mirrorów.
AJ: Nie rozumiem natomiast co w końcu było w sumami kontrolnymi tarballa – bo po tym w końcu się ludzie z Gentoo zorientowali – dlaczego nie zostały sprawdzone wcześniej?
też mnie to nurtuje; każdorazowa inicjatywa instalacji softu powinna skończyć się błędem Manifestu.
Myślę, że najbardziej prawdopodobny scenariusz jest taki:
maintainer pakietu wstawił zainfekowany soft wraz z odpowiadającą mu sumą kontrolną pakietu. Skąd ją wziął? wykonał ebuild digest, ponieważ twórca nie publikował sum kontrolnych.
Czy można winić maintainera? nie specjalnie. Chciał ułatwić instalację, a pobierając pakiet ze strony nikt by nie uniknął infekcji. Z drugiej strony, własnoręczne liczenie sum kontrolnych w przypadku ich braku na stronie to branie odpowiedzialności za kogoś innego.
Gdybym to ja wstawił ten pakiet, byłoby mi wstyd, niemniej jednak warto wspomnieć że ebuild w Gentoo przez całą swoją historię w Portage oznaczony był i jest jako testowy.
W ten sposób to zagrożenie dotyczy każdego sprzętu komputerowego. Nie sztuka "zawirusować" komputer przez świadomą (!) akcję użytkownika. To nie ma nic wspólnego z Linuksem, czy jakimkolwiek innym systemem.
Przewagą Linuksa i w dużej mierze także Maca nad windowsem jest praktycznie brak exploitowalnych dziur w kernelu, powłoce, a przede wszytkim w aplikacjach użytkowych.
Wirusy najczęściej dostają się przez błędy w systemie i oprogramowaniu: kulawa obsługa USB pod windows, żałosny FAT12/16, msoffice będące rajem dla exploitów, tak samo IE, teraz świetny UAC będący zaprojektowaną luką bezpieczeństwa. To są problemy i konkretne wady systemu.
To, że użytkownik może sobie sam zainstalować szkodliwą aplikację, to nie wada systemu. Ano może, bo słaby to byłby system gdyby nie mógł instalować sobie programów.
@oO: Ech, i znowu brednie…
W Linuksie dziury w samym kernelu pojawiaja sie co kilka miesiecy. Dokladnie jak w Windows. Fakt, w przypadku innych systemow pojawiaja sie rzadziej.
Wirusy praktycznie nigdy nie wykorzystuja bledow w systemie i oprogramowaniu – wykorzystuja glupote uzytkownikow. Btw, wlasnie stwierdziles, ze linuksowe sudo to zaprojektowana luka bezpieczenstwa. Mocne.
Rozumiem, że te "brednie" to twoja ocena własnego komentarza?
Najczęstszym powodem zarażenia są właśnie błędy w oprogramowaniu: IE, msoffice, windows (pendrivy). Świadoma akcja użytkownika jest na 2 miejscu, a i tak część z nich podpada pod błąd w systemie – user uruchamia przecież program z ograniczonymi prawami, a tu magicznie cały system zawirusowany.
A o problemach z UAC sobie poczytaj. Gdyby UAC był jak sudo, to wszystko by było ok. Ale MS nadaje uprawnienia z góry dla "zaufanych" aplikacji, co exploituje się w kilku linijkach. Choć to i tak niewiele zmienia, bo i tak na windowsie wszyscy siedzą na koncie admina, bo inaczej ciężko wytrzymać nerwowo. Pewnie dlatego MS nie zamierza naprawiać tego problemu co już dawno zapowiedział.
@trash:
biega o to, ze pisząc makro do pewnego arkusza kalkulacyjnego zapisującego swoje pliki zazwyczaj jako *.xls można wpływać nie tylko na arkusz ale i na inne czynniki/składniki w tym systemu. Odpalając makro pod Calc'iem nic poza pakietem OO nie zrobisz.
" FAT12/16, msoffice będące rajem dla exploitów, tak samo IE, teraz świetny UAC będący zaprojektowaną luką " – no super widziałeś kiedyż UAC na oczy ??? człowieku o czym ty pisze FAT12/16 ??????? no ludzie – Jeżeli taki unreal pojawił się w formie binarnej w jakiejkolwek dystrybucji to jest porażka bezpieczeńswa !!! bo nie dosć że ufasz oficialnym repo to jeszczo one same są źrudłem zagrożenia – co jak co ale z windows update wirusa nie uświadczysz .
A lukki wystepują w każdym oprogramowaniu – i tój brak exploitów no zajb…. tekst to na ten brak exploitów debian i inne distra wydają tyle poprawionych pakietów
1) naucz się pisać po polsku
2) dowiedz się czegokolwiek w temacie na który się wypowiadasz
3) w OpenSource poprawki dotyczą najczęściej modyfikacji funkcjonalności albo poprawek błędów funkcjonalnych, a nie bezpieczeństwa. Stąd tak wiele uaktualnień.
W tym temacie zamknięte oprogramowanie kuleje najbardziej, bo producent jeśli cokolwiek zechce zrobić, to jedynie poprawić ważną lukę bezpieczeństwa. Na pewno nie masz szans na poprawkę błędu, który nie stwarza dużego zagrożenia. Spróbuj wyegzekwować od MS czy innych tego typu firm poprawienia błędnych zachowań programu czy crashy. Bez szans. Tam liczy się tylko kasa. Kupiłeś, to płacz i płać. I ciesz się, jak po kilku miesiącach dostaniesz poprawkę na poważne luki bezpieczeństwa.
Przy zamkniętym oprogramowaniu jest jeszcze gorzej. Gdy np. luka bezpieczeństwa dotyczy API i jest wymagana jego zmiana, to w świecie zamkniętego oprogramowania jest dramat i zwykle trzeba czekać na nową generację systemu, choć i ta nowa może być skażona koniecznością wstecznej kompatybilności. Oczywiście przy otwartym oprogramowaniu też jest dramat, ale z uwagi na dostępność kodów źródłowych, znacznie mniejszy, bo nie ma aż tak bezwzględnego przymusu kompatybilności binarek jak w świecie zamkniętego oprogramowania.
Potrafisz podac jakikolwiek przyklad luki bezpieczenstwa, ktorej zalatanie wymagaloby zmiany API? Ja potrafie – ale tylko z uniksow; funkcje dziurawe by design sa nadal obecne w kazdym uniksowatym, takze w Linuksie.
Nie potrafi, bo przecież napisał, że takie dziury nie są łatane
Ja potrafie: WoW – windows on windows nt – emulacja trybu dos w systemach nt miala lukę od wersji 4.0 do 7 włącznie – jedyne rozwiązanie to wyłączenie kompatybilności z dos. wirusy na pendrive -od 98 do 7, z tym że w 7 wyłączono domyślnie autostart, ale luki którą wykorzystują te wirusy nie załatano [czemu?]
> "udało się podmienić plik Unreal3.2.8.1.tar.gz zawierający kod źródłowy
> programy na własny zbiór"
Plik można zastąpić jedynie innym plikiem – a nie "zbiorem".
To to samo. W literaturze fachowej sprzed 20 lat często używało się słowa "zbiór" jako tłumaczenie "file". Potem utarło się "plik", i tak zostało. Dzisiaj "zbiór" trochę trąci myszką (którą na szczęście dzisiaj "klikamy", a nie "tupiemy" czy "pukamy", co niektórzy ówcześni autorzy preferowali
)
To nie to samo – wystarczy porównać znaczenie określeń "set" oraz "file".
A to, że w literaturze – zwłaszcza tej pisanej przez studentów-"Murzynów", i wydawanej potem pod nazwiskiem Jana B. – było sporo takich błędów, to wcale nie znaczy, że do dziś dnia należy je kultywować.
mi by się podobało "pukanie ikon"
@AJ:
przetupałem myszą do napisu "Odpowiedz na komentarz" i go tupnąłem. Serwer przeczytał zbiór WordPress:plik.php i po przetworzeniu wysłał do mojego kompa.
.
O pukaniu myszą to nie słyszałem – ale tupanie jest fajne. Mnie się podoba. Z zbiór zamiast plik to używało sporo osób i w książkach i w wczesnych programach tv (wtedy zazwyczaj była Spektrumna) – "zapisać zbiór na taśmę".
.
Pliki to mi się jakoś kojarzą z Janem-B.
Nieprawda. To że w jednym języku dwa słowa znaczą coś zupełnie innego nie znaczy, że w innym nie mogą one stanowić wyrazów bliskoznacznych lub synonimów (przynajmniej w pewnym zawężonym znaczeniu).
Idąc twoim tokiem rozumowania, dziecięcej zabawki nie można nazywać zamiennie "pociągiem" lub "kolejką", bo pociąg to "train", a kolejka to "queue" – a to przecież kompletnie różne rzeczy?
Do początku lat 90. "zbiór" (od "zbioru danych") funkcjonował nie tylko w literaturze, ale i w wielu polskich programach DOSowych. Chyba dopiero polskie wersje Windowsa, Worda i Excela przypieczętowały ostateczne zwycięstwo "pliku", zaś "zbiór" stał się raczej archaizmem.
W języku polskim "zbiór" i "plik" NIGDY nie były synonimami. Owszem, miewały miejsce próby lansowania błędnego tłumaczenia angielskiego "file" na polski "zbiór" – i to wszystko.
A czy ten trojan/wirus mógł coś zrobić. Fakt posiadania go w systemie nic nie znaczy. Jeśli był aktywny – uruchamiał się/pracował to wtedy to wszystko (artykuł) miało by jakiś sens. Generalnie uważam, że artykuł nic nie wnosi.
Powinni sami go sobie wprowadzić? d-:
@czako:
Ano mógł, szczególnie jeżeli skrypt instalacyjny uruchomiłeś z prawami administratora. Wtedy taki program może zrobić prawie wszystko co chce.
Taka kwestia niezabezpieczenia kodu nie zależy od systemu operacyjnego. To kwestia zaufania do dystrybutora kodu i jego solidności zabezpieczania repozytoriów.
A jak moglibyśmy się zabezpieczyć gdyby twórcy popularnego programu dodali destrukcyjny kod? Też moglibyśmy się o tym przekonać po pewnym czasie. Albo gdyby jakiś administrator serwera sam podmieniał kod?
Wszystko opiera się na zaufaniu do konkretnych osób, organizacji lub instytucji.
He, he! Tak czy siak prowokacja, FUD czy inna manipulacja komuś się udała.
Dziś pół internetu huczy o "Morderczym trojanie porywającym/pożerającym Linuksy!!!", jutro pewnie będzie huczała cała sieć.
I jakoś mało widzę rzetelnych informacji że skompromitowały się źródła, a w sumie administratorzy serwerów, raptem wszyscy zaczęli się martwić o bezpieczeństwo Linuksa.
Ten idiotyzm piszących jest zastanawiająco zaraźliwy, natomiast głosów rozsądnych dziś jest zadziwiająco mało. Wzorcowym przykładem są Dobre Programy. Czyżby centralne sterowanie?
Ciekawie się to obserwuje, he, he!
Przeciez w przypadku malware'u na Windows dziala to dokladnie w ten sam sposob.
cytat z heiseonline.pl
czyli bez wymuszenia (przegenerowanie haszy) nie dało się wersji affected zainstalować
Jeżeli infekcja polegała na dodaniu w pewnym miejscu wywołania syscall(), to pod Windows syscall jako takiego nie ma. Poza tym z ręką na sercu – kto pod Windows kompiluje z tarballa, jak jest do ściągnięcia binarka?
Szkoda, ze prawdopodobnie taki zimny prysznic nie zostanie wykorzystany dla uszczelnienia Linuxa.
Na pewno w opensuse, a podejrzewam, ze w innych distrach, bezpieczenstwo konczy sie na podpisie repo. Tj. jesli cos idzie z repo, to znaczy, ze jest bezpieczne. Kompletna bzdura.
Windows a rebours zyskal przez te wszystkie ataki i dziury, bo i MS i firmy produkujace soft antywir. musialy po prostu podnosic poziom. W Linuxie przyznaje sporo zrobiono "na wszelki wypadek", ale czesc rozwiazan jest po prostu odlozona gdzies na bok (vide: zwolnienie teamu AppArmor przez Novella). Najgorzej ma sie chyba sprawa z Applem.
Bezpieczny, bo niepopularny? Slabo.
W Apple sytuacja ma sie podobnie, jak w Linuksie – co prawda wykorzystywany mechanizm zabezpieczen (framework Mandatory Access Control wziety z FreeBSD oraz "seatbelt") jest lepszy, ale nadal bardziej chroni to przed przypadkowym uruchomieniem malware'u przez uzytkownika niz przed uruchomieniem celowym, "w dobrej wierze".