The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в Glibc ld.so, позволяющая получить права root в системе, opennews (??), 04-Окт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +7 +/
Сообщение от Аноним (3), 04-Окт-23, 00:19 
Это же сколько раз они на одни и те же грабли наступили с переменными окружения в suid-программах?

https://www.opennet.dev/28338
https://www.opennet.dev/28390
https://www.opennet.dev/40667
https://www.opennet.dev/46724
https://www.opennet.dev/47722
https://www.opennet.dev/52012

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +2 +/
Сообщение от Аноним (31), 04-Окт-23, 08:04 
Всё как завещали деды!

https://web.mit.edu/~simsong/www/ugh.pdf

The Unix concept called SUID, or setuid, raises as many security problems
as the superuser concept does. SUID is a built-in security hole that provides
a way for regular users to run commands that require special privileges to
operate.
<...>
AT&T was so pleased with the SUID concept that it patented it. The intent
was that SUID would simplify operating system design by obviating the
need for a monolithic subsystem responsible for all aspects of system secu-
rity. Experience has shown that most of Unix's security flaws come from
SUID programs.

Ответить | Правка | Наверх | Cообщить модератору

135. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от InuYasha (??), 05-Окт-23, 17:24 
AT&T - та ещё корпорация зла. Позлее гугла в свои времена.
Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +1 +/
Сообщение от фнон (?), 04-Окт-23, 09:27 
ты понимаешь, что если сделать один раз нормально - то больше код трогать не придется
а так еще поколения шышников будут кормиться на исправлении ошибок
(вспоминается анекдот про молодого адвоката, который выиграл семейное дело на первом же заседании)
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

59. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +1 +/
Сообщение от Пряник (?), 04-Окт-23, 09:51 
Вообще концепция suid напрягает.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

78. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Чи (?), 04-Окт-23, 11:31 
Ну отказаться от этой концепции видимо уже не получится. Как вариант обмазать все эти суид бинари правилами selinux в обязательно порядке.
Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (-), 04-Окт-23, 13:58 
SELinux - лишнее звено.
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  –1 +/
Сообщение от Аноним (91), 04-Окт-23, 14:29 
Почему не отказаться? Что из этого нельзя выкинуть? А других гнилых бинарей у меня и нет.

/bin/su
/bin/passwd
/usr/bin/crontab
/usr/bin/cgexec
/usr/bin/newuidmap
/usr/bin/chsh
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/nvidia-modprobe
/usr/bin/ping
/usr/bin/expiry
/usr/bin/chage
/usr/bin/newgidmap
/usr/bin/chfn

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

111. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +1 +/
Сообщение от Аноним (111), 04-Окт-23, 18:37 
Получится, если будет политическая воля. Более 20 лет шло балабольство о невозможности отказа от GIL. Потом пришёл Micro$oft, нанял ключевых разрабов, и в течение года проблема будет решена, а несогласным придётся утереться. Если найдётся корпорация, которая смажет всё деньгами - проблема мигом будет решена. И suid уберут, и программы, которые нужно будет править, либо поправят, либо на свалку истории отправят.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

146. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от uis (??), 06-Окт-23, 12:24 
Эммм... POSIX file capabilities.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

115. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +4 +/
Сообщение от Аноним (115), 04-Окт-23, 19:42 
Причем каждый раз когда я пишу про SUID на этом форуме всегда найдется парочка долбоящеров, которые будут оборонять эту дрянь и пищать про какой-то там UNIX way!!!

Решается эта проблема так:
1) Реализовать полноценные ACL на уровне ядра, а не тот позорный мусор, который опциональный и не работает как надо.
2) Начинайте принудительно и неотключаемо применять ACL ко всем объектам:
- файлам
- каталогам
- сокетам
- процессам
- потокам
- каналам (pipes)
3) Принудительно включить мандатный контроль, работающий поверх тех же ACL, но позволяющий создавать виртуальные объекты доверия, которые могут стать субъектом политики.
4) Вменять Targeted Policy для всего софта, который дистрибутив считает частью базовой системы пространства пользователя, а остальные 9000 пакетов из репозиториев/PPA, ставить в помойку^W /opt
5) Дать утилиты для работы с этим со всем

Вместо того, чтобы в прямом смысле слова КАЖДАЯ программа работающая с SUID могла поломать вам систему, просто украдите уже в Windows. Или сделайте лучше, только хватит защищать SUID-бэкдоры, которые раскиданы по всяким линуксам.

Причем там ведь даже и патенты все 100 лет как кончились и есть открытые описания стандартов. Microsoft даже пытался это стандартизировать... но  нет.

1) Решается через NT ACL. С натяжкой можно NFSv4 ACL, но лучше сразу взять полнофункциональный вариант
2) Это решает SDDL, который привносит понятие дескриптора безопасности и вменяет DACL и SACL
3) Сделать нужно одну обязательную систему мандатного контроля, а не 2,5 опциональных
4) И политику нужно писать на системы мандатного контроля, а не как в Debian
5) Это самое сложное, потому что нужны не только утилиты настройки, на и пересмотреть целый ряд системных утилит
Просто подумайте о том, какие права нужны утилите ping и что произойдет если не дать её работать через ядро. (вы не увидите ни latency ни jitter не посчитаете в юзерспейсе, там цифры будут на порядок отличаться от реальности)

Если кто-то спросит, скажите Аноним разрешил скоммуниздить у MS.

Прекратите верить в радужных единорогов, фей, барабашек и безопасность Unix с SUID-битами и выключенным мандатным контролем при полном отсутствии ACL, вместо которых в ОС модель прав из 70-х. Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить.

P.S. И вот только не надо рассказывать мне сказки про безопасность Windows. У нее все проблемы исторически из-за того что почти все пользователи сидят из-под админских учеток и качают из интернета бекдоры, не понимая что они запускают. Если вы дадите любую Ubuntu на такую же целевую аудиторию с ней будет  еще хуже.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

117. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +1 +/
Сообщение от Анонин (?), 04-Окт-23, 21:14 
Просто интересно, а если ли хоть какая-то система где все перечисленное реализовано, причем правильно, или хотя бы близко к нему?

И насколько оно юзерфрендли? Потому что за линуксом сидят не только пользователи с отдельным отделом ИБ, но и обычное юзверье, которому все ваши ACL и политики - китайская грамота.

Ответить | Правка | Наверх | Cообщить модератору

119. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от User (??), 04-Окт-23, 22:21 
Осталось ответить на вопрос "ну и вот нахрена это ХОТЬ КОМУ-НИБУДЬ чтоб это самому делать или хотя бы денег за это заплатить"? И можно в путь.
Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

129. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (115), 05-Окт-23, 12:54 
Вопросы по всем перечисленным пунктам многократно поднимались в списках рассылки ядра, были неоднократные попытки реализовать и Rich ACLs и дескрипторы. Практика показывает, что это не вопрос денег, это вопрос принятия патчей.
- Бешенные бараны упираются рогами в землю и не хотят ни применять патчи, ни пользоваться этим, потому что это "как в Windows". Если они узнали бы что разработчики Windows едят еду и пьёт воду, они бы объявили сухую голодовку и сдохли бы в знак протеста.
- Тупые овцы не понимают, зачем вообще всё это нужно, потому что не видели задач вне локалкоста. Они прекрасно живут и так, и УМВР и "ви врёти всё".
- Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через докер от рута, которая что-то от чего-то защищает через пространства имён.
Проблема прежде всего в компетенции...
Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от User (??), 05-Окт-23, 19:07 
>[оверквотинг удален]
> - Бешенные бараны упираются рогами в землю и не хотят ни применять
> патчи, ни пользоваться этим, потому что это "как в Windows". Если
> они узнали бы что разработчики Windows едят еду и пьёт воду,
> они бы объявили сухую голодовку и сдохли бы в знак протеста.
> - Тупые овцы не понимают, зачем вообще всё это нужно, потому что
> не видели задач вне локалкоста. Они прекрасно живут и так, и
> УМВР и "ви врёти всё".
> - Религиозные ослы верят в единорогов, гномов и в контейнерную изоляцию, через
> докер от рута, которая что-то от чего-то защищает через пространства имён.
> Проблема прежде всего в компетенции...

Ну, в общем я и говорю - примерно всем пох. Или "не пох" в степени недостаточной чтоб хоть что-то в этом направлении сделать. ЕМНИП, NFSv4 acl слабали санки для солярки - и уже оттуда оно оно кои-8-как доползло и до linux'ов - и то не так, чтобы полностью - самбе было надо, они накостылили поверх чего умели и как могли, остальным как было пох - так и осталось.

Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (120), 04-Окт-23, 22:28 
> Решается эта проблема так:

Получается Windows. Но ведь она давно уже есть, зачем изобретать велосипед?

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

128. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +3 +/
Сообщение от Аноним (115), 05-Окт-23, 12:18 
Во-первых не просто Windows, а именно Windows NT.
Внутри Windows есть огромное количество невменяемого наследия DOS/Windows9x даже в современных версиях, которое мешает ей жить и создаёт тонну дырок в безопасности. Понимаете ли в чем дело... Всё что я писал в своем предыдущем длинном посте не распространяется на legacy-компоненты, и это страшная дыра. Просто вдумайтесь (!!!), Spooler - это legacy-компонент из Win9x. Еще раз прочитайте медленно и ужаснитесь: "Вся подсистема печати Windows - наследие DOS/Windows 9x". И она дырявая, потому что предпечатный рендеринг шрифтов GDI-принтера делается модулем ядра GDI (тот самый win32k.sys с его синими экранами), а пользователи могут при подключении к сетевому принтеру по SMB загрузить и установить драйвер (драйвер, Карл!) с внешнего компьютера в обход проверок от лица пользователя с пониженными привилегиями. А я напоминаю, что всякий RICOH и Kyocera не стесняются в кастомизации рендеринга шрифтов и ставят WDM-драйвер уровня ядра, который подменяет стандартную логику работы GDI конкретно с их железками.
А еще в Windows настолько страшный Virtual Filesystem (VFS-драйвер), что на нем стоит мораторий на любые изменения в коде. Оно еле-еле работает, потому что с одной стороны оно предполагает, что всё должно быть в UCS-2 (даже не в UTF-16), но при этом должна быть обратная совместимость с 8.3 именованием каталогов и файлов и не только в формате ANSI CP-****, а именно в тех самых IBM-кодировка типа CP866 или CP478. VFS Windows работает настолько плохо, что в общем случае для рекурсивного удаления каталога даже через современный PowerShell требуется целый скрипт учитывающий все legacy-штуки, особенно оформленные ReparsePoint-объекты и очень сбоку прикрученные туда ACE/ACL, потому что изначально-то в DOS всего этого не было. И я еще не начал про SMB1, NetBIOS и прочее наследие IBM, которое застряло в Windows NT ради обратной совместимости, не только с Win9x, но и с OS/2. И это лишь пара примеров...
Короче, вам это всё не надо. Вдумайтесь, Microsoft десятилетиями медленно пытается херить эти подсистемы, но там реализация всей этой архитектуры мягко говоря слабоватая. Legacy Windows - это рак, она больна и её десятилетиями лечат вырезая метастазы:
- Разделить службы (демоны) от пользовательских процессов (Windows Vista)
- Администратор больше не равен по правам Системе. LOCAL SYSTEM = root в Windows. (Windows Vista)
- Понизить в правах планировщик задач и сами задачи сделать подконтрольнее (Windows Vista)
- Добавить возможность запускать процессы пользователя с пониженными привилегиями относительно прав самого пользователя (Windows 8)
- Научить подсистему безопасности тому, что служба может быть запущена с привилегиями ниже пользовательских и не иметь возможности ни работать вне пользовательской сессии, ни к другим пользователям не лезть (Windows 10)
Сейчас их безопасники на конференциях в очередной раз поднимают вопросы:
1) Как отобрать у всех админов, чтобы пользователи могли работать без страданий, но при этом в ограниченных сессиях.
2) Пересмотреть реализацию Capabilities в ядре так, чтобы пользователь мог контролировать к каким устройствам запущенное им приложение имеет доступ, а к каким он запретил
3) Как сделать так, чтобы это было не сильно заоверинженирнуто и разработчики этим пользовались, а не пытались обойти.
Поймите, там проблем столько, что иногда проще переписать с нуля. Они же так уже делали, когда переходили на WinNT.

Во-вторых Windows NT это не 100% оригинальная разработка, а вольная интерпретация архитектуры VMS для x86-чипов. И вот поверх этого всего в сочетании с Win32 народилось много всего.
Просто людям (я живьем таких встречал) почему-то кажется, будто есть только UNIX и ему подобные ОС, а Windows она такая единственная протестная, которая из принципа не следует стандартам POSIX и не любит "UNIX way". На самом же деле она написана архитекторами VMS и продолжает развитие другой линейки ОС.
Ну возьмите лучшие практики оттуда и примените себе... Microsoft же всегда так делал. Сетевой стек у них сначала писала IBM, потом Cisco, потом они его у BSD взяли, параллельно доробатывая свой NDIS и WFP. Протокол RDP они лицензировали у Citrix, а Hyper-V это порт Xen на Windows причем опять самими же авторами. Не вижу никакой проблемы.

> Но ведь она давно уже есть, зачем изобретать велосипед?

Windows очень старый трехколесный велосипед с отваливающимся рулём, но третье колесо вроде бы не нужно, но без него никуда не едет, поэтому мы приделаем еще 1 колесо, для плавности, главное чтобы сидеть было комфортно.
При этом Linux, это велосипед без руля с квадратными колесами и дилдаком вместо седушки, чтобы при каждом прокручивании педалей пользователь получал специфическое удовольствие. А если ему нужно повернуть, то нужно соскочить, переставить велосипед и только потом ехать в другом направлении (это я про маразм вокруг конфигурирование SELinux и ему подобных решений).
На минуточку, SELinux и его контексты это именно то, что реализуется вместо дескрипторов SDDL. А еще он имеет свою собственную эксклюзивную для него реализацию ACE/ACL на уровне ядра. Но всё это бесполезно, потому что по всей ОС раскиданы SUID-утилиты (модель прав из 70-х годов), которые всё это обходят. Что возвращает нас обратно к теме новости.

Ну не хотите как в Windows, ну не надо, но сделайте лучше и закопайте чертов SUID, иначе это никогда не кончится. Это тот самый пример уязвимости by design.

Ответить | Правка | Наверх | Cообщить модератору

130. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (130), 05-Окт-23, 13:05 
Suid не обходит selinux.
Ответить | Правка | Наверх | Cообщить модератору

131. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (115), 05-Окт-23, 13:26 
Он не обходит его на этапе работы с контекстом вызываемой утилиты, в том и только в том случае если есть специально оформленное правило в рамках Targeted Policy. Политика мандатного контроля по умолчанию всегда является таргетированной, она не распространяется на ВСЁ, за исключением единичных случаев, когда в рамках корпоративного использования её вменяют на шаблонизированные рабочие станции и сервера.

Он обходит его на этапе запуска. SELinux позволяет существовать возможности неподконтрольного ему поднятия привилегий даже в объявленном и подконтрольном ему контексте.

Ну то есть у вас дыра в заборе и двери в доме нарастапашку. Грабители вынесли абсолютно всё из дома, но в сарай не попали, сарай закрыт на ключ. Как-то так...

Вот есть отличное видео о том как сейчас работает SELinux: https://www.youtube.com/watch?v=fB2b-lTjCQA

Ответить | Правка | Наверх | Cообщить модератору

157. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (157), 08-Окт-23, 21:13 
> из принципа не следует стандартам POSIX

Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё, что напишут "Developers, Developers", работало только в Пинде и нигде больше - без переписывания.

> по всей ОС раскиданы SUID-утилиты

systemd монтирует все разделы (включая автоматические) с nosuid, кроме явно определенных админом в /etc/fstab. См. выхлоп findmnt.
Выносим /usr/{bin,lib} в отдельный раздел (или subvolume на Btrfs). Всё остальное монтируем с nosuid. И всё работает. Ничего не сломалось - невероятно!

А в /usr/ файлы попадают только из пакетного менеджера, не минуя пары глаз сопроводителя.

Утилиты, использующие SUID, в современных системах можно по пальцам двух рук пересчитать. Большинство не нужно пользователю в повседневной работе на предварительно настроенной системе.
Для всего остального (обычно пускаемого из-под root) давно используют man 7 capabilities.

Находим все SUID-файлы: `# find /usr -type f -perm /u=s,g=s -printf '%M\t%H/%P\n' 2>/dev/null`
Блокируем их вызов в программах через AppaArmor/SELinux: "audit deny rwklmx /usr/bin/sudo,"

Или запускаем программы изолированно через bwrap/flatpak, где получаем "no new privs" при попытке вызвать SUID-программу.

Linux capabilities также явно разрешаются через MAC и user namespaces.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

159. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от User (??), 10-Окт-23, 09:44 
>> из принципа не следует стандартам POSIX
> Жопslashes, case-нетерпимость, буквы устройств, ФС без DAC и стойкое желание всё это
> насадить всем другим, POSIX-совместимым ОС, а хоть бы и через железных
> вендоров (см. UEFI), -- не дадут соврать. Из принципа. Чтобы всё,
> что напишут "Developers, Developers", работало только в Пинде и нигде больше
> - без переписывания.

Нууу... вы так говорите, будто в этом POSIX in our days есть хоть что-то хорошее - это даже не говоря о том, что на "posix compilance" linux "in general" никогда и не закладывался )

Ответить | Правка | Наверх | Cообщить модератору

160. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Аноним (160), 10-Окт-23, 10:04 
Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.
Ответить | Правка | Наверх | Cообщить модератору

161. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от User (??), 10-Окт-23, 10:14 
> Одна только унификация - на вес золота. Много хорошего, за неимением лучшего.

Ну вот кушайте posix acl, не обляпайтесь. Ой, а он !внезапно! не часть POSIX. "У" - унификация! "Г"... каквсигда.

Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от Kuromi (ok), 06-Окт-23, 17:21 
"Я в реальной жизни встречал баранов, которые выключили SELinux, понаставили "chmod 777" и пренебрежительно рассказывают мне о высочайшей безопасности Linux  и про то что Windows на железо им страшно ставить. "

Ну разумеется. Потому что безопасность и удобство очень редко идут рука об руку и в какой-то момент любой человек может сказать "да к черту, залолбало разбираться почему Х не запускается или Y валится с ошибкой потому что что-то где-то права не такие как надо (по умолчанию или наоборот)." И тогда в ход идут "три топора" (извините, не удержался). Это чаще всего не баранство, а просто "усталось". По той же самой причине народ прется через рельсы (и попадает регулярно под поезд) когда обходной безопасный путь "всего на килотметр-два длиннее".

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

156. "Уязвимость в Glibc ld.so, позволяющая получить права root в ..."  +/
Сообщение от крокодил мимо.. (?), 08-Окт-23, 18:53 
> Решается эта проблема так:

кмк, необходимо и достаточно внимательно аудировать код утилит, требующих 4000..
например, в базе OpenBSD имеем (с инодами в первом столбце):

2125487 -r-sr-xr-x 2 root bin /sbin/ping*
2125487 -r-sr-xr-x 2 root bin /sbin/ping6*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chfn*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chpass*
1762855 -r-sr-xr-x 3 root bin /usr/bin/chsh*
1762610 -r-sr-xr-x 1 root bin /usr/bin/doas*
1762699 -r-sr-xr-x 1 root bin /usr/bin/passwd*
1762769 -r-sr-xr-x 1 root bin /usr/bin/su*
1814401 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_chpass*
1814402 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_lchpass*
1814404 -r-sr-xr-x 1 root auth /usr/libexec/auth/login_passwd*
1814433 -r-sr-xr-x 1 root bin /usr/libexec/lockspool*
1814455 -r-sr-xr-x 1 root bin /usr/libexec/ssh-keysign*
1840372 -r-sr-xr-x 2 root bin /usr/sbin/traceroute*
1840372 -r-sr-xr-x 2 root bin /usr/sbin/traceroute6*

итого 11 программ, acl не реализован (за ненадобностью.. хех..), пользуем bsdgroups (то самое, лохматое, конца 70-ых)..

ещё один пример - утилита doas, которая появилась "от безысходности", если можно так сказать :))..
другими словами, можно вспомнить профессора Преображенского, объясняющего Борменталю, что порядок должен быть прежде всего в голове..

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру