Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundację Dzieciom „Zdążyć z Pomocą”.
Więcej informacji na dug.net.pl/pomagamy/.

#1 2014-04-08 20:34:46

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Dziura w openssl

http://niebezpiecznik.pl/post/krytyczna-dziura-w-op … -to-od-2-lat/

brak tzw. bound checka w obsłudze heartbeatu TLS może powodować ujawnienie 64k pamięci serwera. Na błąd podatne są wersje od 1.0.1 do 1.0.1f oraz 1.0.2-beta wraz z 1.0.2-beta1. —Błąd odkrył Neel Mehta z Google Security.

Lepiej łatajcie. Póki co poprawiona wersja jest w sidzie:

Kod:

# apt-cache policy openssl
openssl:
  Installed: 1.0.1g-1
  Candidate: 1.0.1g-1
  Version table:
     1.0.2~beta1-1 0
        130 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
 *** 1.0.1g-1 0
        500 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.1f-1 0
        900 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages

Nie ma to jak społeczność weryfikująca kod. xD

Offline

 

#2 2014-04-08 20:36:47

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

Było w CB dzisiaj rano.

A na społeczność możesz nie miauczeć, ciekawe, jak często szacowni producenci  routerów z VPN zapewniają łatki dla swoich systemów, na których chodzą miliony ich urządzeń.

Po ataku na serwery BGP, kiedy cały FB leciał przez Chiny, jakoś nie zauważyłem, żeby był dużo większy ruch w aktualizacjach softu na routery.

PS
Czy W BGP dalej używa się haseł hashowanych md5?

Pytam, bo sam podsłuch szyfrowania SSL na wiele się nie zda, jeśli ten szyfrowany sygnał nie leci przez infrastrukturę do podsłuchu, więc trzeba do tego zrobić jeden z dwóch ataków, albo włamanie na DNS, co łatwo wykryć i przeciwdziałać, albo włamanie na BGP, gdzie można zdecydować o przekierowaniu milionów pakietów przez inną część sieci, czego wielu ludzi nie zauważy w ogóle.
Bo niby kto pamięta, że pingi do banku, to 21,3 ms, i zacznie alarm, kiedy będą wynosić 134,7ms.

Ostatnio edytowany przez Jacekalex (2014-04-08 20:49:42)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#3 2014-04-08 20:42:01

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Dziura w openssl

A co to CB ? xD A już wiem. xD

Ostatnio edytowany przez morfik (2014-04-08 20:42:11)

Offline

 

#4 2014-04-08 20:49:21

enether
wiecznie niewyspany
Zarejestrowany: 2012-05-01

Re: Dziura w openssl

Żadnego łatania paczkami z sida...

Od tego są poprawki na paczki w gałęzi security by z nich korzystać ;) I jak rano serwery łatałem już była poprawiona wersja dla Wheezy'ego.
https://www.debian.org/security/2014/dsa-2896

Offline

 

#5 2014-04-08 20:54:32

yossarian
Szczawiożerca
Skąd: Shangri-La
Zarejestrowany: 2011-04-25

Re: Dziura w openssl

The oldstable distribution (squeeze) is not affected by this vulnerability.

For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5.

For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.

For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1.

We recommend that you upgrade your openssl packages.

morfik napisał(-a):

Nie ma to jak społeczność weryfikująca kod. xD

Ile kodu sam zweryfikowałas?

Offline

 

#6 2014-04-08 21:00:15

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

Tak przy okazji, znacie jakieś automatyczne skrypty, które bez specjalnego angażowania administratora, automatycznie wygenerują nowy
RootCA i certy dla poszczególnych usług?

Zamierzam sobie coś podobnego skołować albo wyrzeźbić, i zastanawiam się, czy użyć expecta, czy kombinować z perlem.

W standardowych openssl, ca.pl trzeba co chwila tłuc hasła, potwierdzać informacje, potem na jednej maszynie jest pół godziny pieprzenia.

[UWAGA]
Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL, żeby być pewnym bezpieczeństwa usług.
Skąd pewność, że cert prywatny nie wyciekł na starej wersji biblioteki? i nie fruwa gdzieś na necie?
[/UWAGA]

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-04-08 21:00:46)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#7 2014-04-08 21:07:48

enether
wiecznie niewyspany
Zarejestrowany: 2012-05-01

Re: Dziura w openssl

Zauważyli zauważyli ;) I po ręcznej zabawie na dwóch maszynach stwierdzono że tą metodą to się można bawić dłuższy czas.

Offline

 

#8 2014-04-08 21:20:35

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Dziura w openssl

E tam, ja nie miauczę. xD No ale 2 lata? xD

Ile kodu sam zweryfikowałas?

Ja nie umiem kodzić, więc to pytanie nie do mnie, tylko do tych co się w tym orientują, a ci jak jeden mąż mówią, że ktoś to weryfikuje. xD To jest największy problem open source i zarazem fałszywe poczucie bezpieczeństwa, że ktoś się doszuka, że ktoś znajdzie, problem w tym, że niewielu w ogóle sobie głowę tym zawraca, oczywiście z tych niezrzeszonych z danym projektem. I to jest fakt.

Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL,

No skoro przez 2 lata można było sobie pozyskać taki cert z servera, to raczej trzeba wymienić. Póki co, to google i riseup zmienili do poczteksa i jabbera, przynajmniej tyle mi wyrzuciło jak n arazie.

Offline

 

#9 2014-04-08 21:27:27

enether
wiecznie niewyspany
Zarejestrowany: 2012-05-01

Re: Dziura w openssl

Swoją drogą ciekawostka, rano aktualizowałem paczki na Debianach, nie chciało restartu usług, teraz pojawiły się kolejne łatki na te same paczki i pyta czy je zrestartować ;)

Więc Ci którzy jak ja łatali rano mają powtórkę z rozrywki...

Offline

 

#10 2014-04-10 11:52:57

remi
amputować akrobatów
Zarejestrowany: 2011-05-27

Re: Dziura w openssl

Cześć. W sieci dostępny jest ciekawy plik, dokument z dn. 24.go lutego ilustrujący: "(..,) a vulnerability introduced to elliptic curve cryptographic protocols when implemented using a function of the OpenSSL cryptographic library". Artykuł - wraz ze szczegółowymi informacjami - stworzony przez Yuval Yarom oraz Naomi Benger, znajduje się pod adresem; http://eprint.iacr.org/2014/140 ("Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack").


Łam ZAsady! wYjąTkÓw jest wIęcej.

Offline

 

#11 2014-04-10 16:22:04

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

2 lata ja pierdziele...ciekawe czy tor się podniesie...(wszystko tam spalone może być...

a propo tora:
http://www.reddit.com/r/DarkNetMarkets/comments/22k … is_affecting/

Ostatnio edytowany przez menel (2014-04-10 16:33:36)

Offline

 

#12 2014-04-10 19:38:33

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

http://article.gmane.org/gmane.os.openbsd.misc/211963
Theo de Raadt - założyciel i przewodniczący projektów OpenBSD i OpenSSH o luce w OpenSSL.
BTW OpenSSH, pomimo tego że korzystało z dziurawej wersji OpenSSL, jest odporne na atak Heartbleed. Niestety nie oznacza to, że wszystko programy korzystające z OpenSSL w OpenBSD są na niego odporne...

Offline

 

#13 2014-04-10 20:24:56

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

a mi to śmierdzi z daleka skoro starsze wersje nie miały hearbeat'a i były bezpieczne to jak ja się pytam można zamiast łatać jeszcze bardziej coś dziurawić. Założę się, że sporo szemranych agencji w tym NSA wiedziały o furtce od początku, bo same ją tam wrzuciły hehe

Tor jest wykończony tym, wszystko spalone tam już jest..

firmy handlujące certami już ręce pewnie zacierają..interes życia..

Ostatnio edytowany przez menel (2014-04-10 20:38:34)

Offline

 

#14 2014-04-10 20:39:24

fervi
Użytkownik
Zarejestrowany: 2010-03-14

Re: Dziura w openssl

@menel
Jest hipoteza informatyczna, według której poprawiając kod - tworzysz kolejnego buga

Niemniej osobiście nie widzę problemu - HTTPS NIGDY nie był bezpieczny

Fervi

Ostatnio edytowany przez fervi (2014-04-10 20:39:52)

Offline

 

#15 2014-04-10 20:45:13

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

jaka tam hipoteza to tylko pokazuje, że w nadchodzących czasach nic nie będzie bezpieczne i takie agendy jak NSA wszędzie włożą swoje łapska bez względu czy to będzie open source czy zamknięte oprogramowanie. Prawda jest taka, że w sieci nic nie jest już bezpieczne a szyfrowania i inne gówna to tylko ułuda poufności mogąca dać bezpieczeństwo jakiemuś maniakowi co sobie szyfruje partycje i łączy się z fejsbukiem ale nie firmom czy infrastrukturom państwowym gdzie jest przepływ strategicznych i wrażliwych danych...

Ostatnio edytowany przez menel (2014-04-10 20:52:59)

Offline

 

#16 2014-04-10 21:09:32

enether
wiecznie niewyspany
Zarejestrowany: 2012-05-01

Re: Dziura w openssl

Abstrahując od tego czy jest to backdoor złych trzyliterowych agencji, błąd programistyczny czy działania jaszczurzych żydomasonów chciałem poinformować tych którzy jeszcze ni e zauważyli że nie tylko serwery są podatne ale i klienci którzy mieli pecha trafić na złośliwy serwer ;)

Swoją drogą, o ile się nie mylę i pamiętam dobrze to i owo o architekturze pamięci procesów w Linuxie to pamięć jądra jak i  każdego z procesów z osobna jest separowana, nawet na jądrze które ominęło błogosławieństwo grseca. Tak?

Offline

 

#17 2014-04-10 21:14:01

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

ja profilaktycznie wymieniłem wszystkie wrażliwsze hasła między innymi do banku..wolę dmuchać na zimne..;)

Ostatnio edytowany przez menel (2014-04-10 21:14:30)

Offline

 

#18 2014-04-10 21:16:25

enether
wiecznie niewyspany
Zarejestrowany: 2012-05-01

Re: Dziura w openssl

Technicznie w przypadku korzystania z 2 factor auth to posiadanie hasła to tylko połowa sukcesu.

Anyway... ktoś coś lepiej kojarzy w temacie architektury pamięci? Bo wybitnie nie mam dziś sił się przebijać przez tony opracowań naukowych.

Offline

 

#19 2014-04-10 23:53:22

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

Ja raczej podejrzewam, że ta dziura w OpenSSl 1.0.x, to wybitny sukces chińskiej myśli technicznej.
Nauczyli się już manipulować od czasu do czasu protokołem routingu dynamicznego BGP, ta dziura w OpenSSL dopełnia kompletu zabawek szpiegowskich.

Szkoda tylko, że tak rzadko inni Ludzie badają zachowanie OpenSSL, bo błąd jest dosyć śmieszny.
Najdłuższy klucz OpenSSL może mieć 64000 bit, a nieszyfrowanym kanałem musi ujawnić klucz publiczny serwera, jeśli ten klucz jest krótszy niż 65535 bitów (zazwyczaj ma 1024 - 4096 bit), to wypluwa znacznie więcej niż klucz?
Ktoś zamiast zmiennej opisującej długość klucza publicznego wsadził 65535 tworząc  stałą wartość?

Toż to praktycznie drobiazg brzemienny w skutki, który w kodzie dosyć ciężko zauważyć.


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#20 2014-04-11 01:13:42

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-ope … eed-bug.html/  <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963

Offline

 

#21 2014-04-11 01:19:46

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...

Ty w to wierzysz? serio?

Zdecydowali się na stworzenie furtki to tak...

W życiu nie uwierzę, że to był przypadek i zwykły błąd, przeoczenie czy jak to zwał...Takie samo gówno jak swojego czasu backdoor w obsd..Dostali hajsy i zrobili swoje...każdego można kupić...trzeba tylko znać cenę i rodzaj waluty..

dla przypomnienia
http://niebezpiecznik.pl/post/fbi-odpowiedzialne-za … psec-openbsd/

Ostatnio edytowany przez menel (2014-04-11 01:35:40)

Offline

 

#22 2014-04-11 01:42:03

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

uzytkownikubunt napisał(-a):

@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-ope … eed-bug.html/  <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963

Bzdury piszesz.

Grsecurity, a zwłaszcza zawarty w nim PAX dodaje solidnych mechanizmów obronnych, jak Mprotect czy Randustack, ale nie ingeruje w samo działanie aplikacji, jeśli aplikacja pod kontrolą wykonuje swoją robotę, to Grsec/Pax nie widzi nic groźnego.
Wszystkie zabezpieczenia typu Grsec/pax dotyczą działania exploitów atakujących aplikacje w przestrzeni pamięci RAM, ale nie ubezpiecza na wypadek celowego czy przypadkowego błędu w działaniu aplikacji, jak w przypadku biblioteki OpenSSL.

Takie rzeczy w przypadku OpenSSH i tuneli VPN potrafi wykrywać Snort przy pomocy specjalnych dekoderów, sprawdzających, jaka ilość danych nieszyfrowanych poprzedza nawiązanie szyfrowanego połączenia.

Natomiast twierdzenie, że większość  "dużych" serwerów chroni Grsec, czy jest tam OpenBSD, to ciężka naiwność, raczej mega pro systemy korporacyjne jak RHEL czy SUSE, gdzie takie ekstremalne zabezpieczenia "nie są potrzebne".

Tutaj nawet nie było senso-stricte backdoora, pozornie OpenSSL działał prawidłowo, tylko zamiast klucza publicznego wysyłał nieszyfrowanym strumieniem 65535 bitów danych, zawierających również klucz prywatny serwera.
Z punktu widzenia modułu Grsec czy systemu ACL to nie był błąd, tylko FEATURE aplikacji.

Fajnie byłoby wiedzieć, skąd w OpenSSL się taki FEATURE znalazł,
ale jak wiadomo, różne Mukhbaraty mają długie ręce.
To mogło być FBI czy NSA (amerykańskie),  rosyjskie FSB, Chińczycy, albo ktokolwiek inny.

Ostatnio edytowany przez Jacekalex (2014-04-11 02:14:49)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#23 2014-04-11 09:30:55

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

Jacekalex napisał(-a):

uzytkownikubunt napisał(-a):

@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-ope … eed-bug.html/  <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963

Bzdury piszesz.

Grsecurity, a zwłaszcza zawarty w nim PAX dodaje solidnych mechanizmów obronnych, jak Mprotect czy Randustack, ale nie ingeruje w samo działanie aplikacji, jeśli aplikacja pod kontrolą wykonuje swoją robotę, to Grsec/Pax nie widzi nic groźnego.
Wszystkie zabezpieczenia typu Grsec/pax dotyczą działania exploitów atakujących aplikacje w przestrzeni pamięci RAM, ale nie ubezpiecza na wypadek celowego czy przypadkowego błędu w działaniu aplikacji, jak w przypadku biblioteki OpenSSL.

Takie rzeczy w przypadku OpenSSH i tuneli VPN potrafi wykrywać Snort przy pomocy specjalnych dekoderów, sprawdzających, jaka ilość danych nieszyfrowanych poprzedza nawiązanie szyfrowanego połączenia.

Natomiast twierdzenie, że większość  "dużych" serwerów chroni Grsec, czy jest tam OpenBSD, to ciężka naiwność, raczej mega pro systemy korporacyjne jak RHEL czy SUSE, gdzie takie ekstremalne zabezpieczenia "nie są potrzebne".

Tutaj nawet nie było senso-stricte backdoora, pozornie OpenSSL działał prawidłowo, tylko zamiast klucza publicznego wysyłał nieszyfrowanym strumieniem 65535 bitów danych, zawierających również klucz prywatny serwera.
Z punktu widzenia modułu Grsec czy systemu ACL to nie był błąd, tylko FEATURE aplikacji.

Fajnie byłoby wiedzieć, skąd w OpenSSL się taki FEATURE znalazł,
ale jak wiadomo, różne Mukhbaraty mają długie ręce.
To mogło być FBI czy NSA (amerykańskie),  rosyjskie FSB, Chińczycy, albo ktokolwiek inny.

A mógłbyś przeczytać to, co zalinkowałem?

Theo de Raadt  napisał(-a):

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed.  Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.


Some other debugging toolkits get them too.  To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

Offline

 

#24 2014-04-11 09:44:37

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

Przeczytałem, inna sprawa, czy w to wierzę.
Identyczny błąd może się powtórzyć np w SSH czy jakimś VPNie, może też w samej bibliotece OpenSSL wyleźć w innym miejscu, inaczej "zaimplementowaną" metodą.
Jak zajrzysz do reguł Snorta przeznaczonych do kontrolowania protokołu SSH, to tam zauważysz inspekcję liczby nieszyfrowanych danych wysyłanych przez serwer SSH przed rozpoczęciem szyfrowania transmisji.

To praktycznie jedyna metoda, aby w przyszłości tak pilnować, czy SSL nie wysyła więcej nieszyfrowanych danych, niż powinno.

Nawiasem pisząc, GnuTLS też ciągle łapie mniejsze lub większe wtopy z bezpieczeństwem, jak ostatnio z tą walidacją certyfikatu.

Ostatnio edytowany przez Jacekalex (2014-04-11 09:45:24)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#25 2014-04-11 10:14:36

bobycob
Członek z Ramienia
Skąd: Wrocław
Zarejestrowany: 2007-08-15

Re: Dziura w openssl

Jacek, BGP wspiera używanie haseł do autoryzacji, ale w praktyce nie jest często używane nawet w dużych (polskich) punktach wymiany ruchu. Są to najczęściej połączenia p2p między routerami do których dostęp mają tylko administratorzy danych routerów. Przy czym standardem jest odpowiednie filtrowanie tras rozgłaszanych na konkretnych połączeń. Czyli nie rozgłosisz nic ponad to co zadeklarowałeś i do tego pokrywa się z danymi w RIPE.
Więc autoryzacja jako taka nie ma tu większego znaczenia.
[edit]
The Great Firewall jak podejrzewam interesujące służby adresy rozgłasza jako własne. W sytuacji gdy operatorzy z którymi łączą się chinole nie zadbali odpowiednie filtry, może z powodu ich rozmiaru, a  skośnooki admin pomylił się w konfiguracji. W konsekwencji te routery dla których to połączenie było najbliższe przełączyły ruch na TGF. Więc nie demonizuj incydentu z Chińskim BGP boś nie onet :). Czesi przypadkiem parę lat temu podobny numer zrobili.

http://www.szkoleniabgp.pl/ciekawostki/zle-skonfigu … ci-internetu/

Ostatnio edytowany przez bobycob (2014-04-11 10:39:02)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)