The OpenNET Project / Index page

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

Уязвимости в Redis и Valkey, позволяющие выполнить код на сервере при наличии доступа к БД

09.10.2025 08:11

Исследователи из компании Wiz выявили в СУБД Redis уязвимость (CVE-2025-49844), позволяющую добиться удалённого выполнения кода (RCE) на сервере. Проблеме присвоен наивысший уровень опасности (CVSS score 10 из 10), при этом для эксплуатации уязвимости атакующий должен иметь возможность отправки запросов к СУБД Redis, допускающей выполнение пользовательских Lua-скриптов.

Помимо публично доступных экземпляров Redis, предоставляющих доступ без аутентификации, уязвимость позволяет скомпрометировать облачные системы и платформы хостинга, поддерживающие сервисы для работы с Redis. По данным компании Wiz сканирование сети выявило около 330 тысяч принимающих соединения Redis-серверов, из которых около 60 тысяч принимают запросы без аутентификации. Предоставляемый проектом Redis официальный образ Docker-контейнера настроен для доступа без аутентификации по умолчанию.

Уязвимость вызвана обращением к уже освобождённой памяти (use-after-free), проявляющимся при манипуляции сборщиком мусора из специально оформленного Lua-скрипта. Проблема позволяет обойти sandbox-изоляцию Lua-окружения в Redis и выполнить код в основной системе с правами пользователя, под которым выполняется СУБД. Примечательно, что ошибка оставалась незамеченной на протяжении 13 лет. Выявившие проблему исследователи продемонстрировали рабочий эксплоит, но детали эксплуатации пока не раскрываются, чтобы дать время на установку обновлений.

Уязвимость также проявляется в проекте Valkey, развивающем форк Redis, поставляемый в большинстве дистрибутивов Linux, включая RedHat Enterprise Linux 10. Уязвимость устранена в выпусках Redis 8.2.2, 8.0.4, 7.4.6, 7.2.11 и 6.2.20, а также в Valkey 8.1.4, 8.0.6 и 7.2.11. Проверить состояние новой версии пакета или подготовки исправления в дистрибутивах можно на следующих страницах: Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo, Arch, FreeBSD, OpenBSD и NetBSD. В качестве обходного пути защиты в СУБД можно отключить выполнение Lua-скриптов, запретив команды EVAL и EVALSHA через ACL.

Дополнительно можно отметить ещё три уязвимости, эксплуатируемые через Lua-скрипты и устранённые в последних версиях Redis и Valkey. Для обходной защиты от данных уязвимостей через ACL можно запретить семейства команд EVAL и FUNCTION.

  • CVE-2025-46817 - целочисленное переполнение в библиотечных Lua-функциях, потенциально позволяющее добиться выполнения своего кода на стороне сервера при запуске специально оформленных Lua-скриптов.
  • CVE-2025-46819 - ошибка, приводящая к чтению данных из области за пределами буфера при выполнении специально оформленного Lua-скрипта. Уязвимость может использоваться для аварийного завершения серверного процесса Redis.
  • CVE-2025-46818 - возможность выполнения команд в контексте другого пользователя СУБД при манипуляции LUA-объектами из специально оформленного Lua-скрипта.


  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Выпуск СУБД Redis 8.2
  3. OpenNews: Уязвимости в СУБД Redis и Valkey
  4. OpenNews: Сравнение производительности СУБД Valkey и Redis
  5. OpenNews: На соревновании Pwn2Own в Берлине продемонстрированы взломы RHEL, Firefox, Redis и VirtualBox
  6. OpenNews: Опубликован Valkey 8.1, форк СУБД Redis от Amazon, Google, Oracle и Ericsson
Автор новости: Асен Тотин
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64022-redis
Ключевые слова: redis, valkey, lua
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 08:25, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А говорили, с луа такого не случится, мол, это не питон.
     
     
  • 2.12, Аноним (12), 09:46, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не в самом языке Lua, а в Jit/Интерпретаторе встроенного LUA, коих бесчисленное множество.
     
     
  • 3.43, Аноним (43), 12:34, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А кто-то мне втирал недавно, что вм это изоляция. :)
     

  • 1.2, Константавр (ok), 08:52, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    >Предоставляемый проектом Redis официальный образ Docker-контейнера настроен для доступа без аутентификации по умолчанию.

    Они же понимал, что никто не будет это настраивать? Заработало, не падает и ура, в продакшен!!!

     
     
  • 2.25, нах. (?), 10:52, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    там диавол в деталях - особенности редисового AUTH таковы, что познакомившись поближе ты и расхочешь его настраивать. Это кривая нашлепка, сделанная видимо в последний момент, по многочисленным просьбам трудящихся.

    Правильная настройка редиса - это изолированная сеть, где чужие не ходят, а не бесполезный auth.

    Ну тебя же не огорчает что у мемкэша его в принципе нет?

     
     
  • 3.34, Аноним (34), 11:13, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Правильная настройка редиса - это изолированная сеть, где чужие не ходят, а не бесполезный auth.

    И по умолчанию при деплое в docker compose это именно так. Но откуда же опеннетным админам локалхоста об этом знать, лол.

     
     
  • 4.36, пох. (?), 11:37, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И по умолчанию при деплое в docker compose это именно так.

    Проблема что компостером пользоваться - харам даже для фанатов дыркера. Им подавай либо безбрежные поля облачков, либо дыркер run.
    Но тогда васян-сайт не работаит! Патамушта тоже не может подключиться.
    И они просто пишут -p  6379:6379 - ВО! Теперь работаит! СОФТ АСТРОЕ!

     
     
  • 5.37, Аноним (34), 11:41, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я осознаю, что тут толстым слоем намазано иронией уровня /s/. Но все же интересно, как профессиональному разработчику, который часто деплоит свои разработки самостоятельно.

    Вот это вот
    > Проблема что компостером пользоваться - харам даже для фанатов дыркера.

    чем обусловлено?

     
     
  • 6.39, User (??), 11:55, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ээээ... так незачем уже, не? Тут даже docker-desktop (Докер-дысктоп, КАРЛ!!!) бубернетис предлагает ).
    Сейчас даже на "одноногом проде"(ТМ) проще k3s "в одну команду (Ну, вы её знаете - curl|sudo...)" поднять поимев с того унифицированный деплой, предсказуемое окружение и интеграцию с инфраструктурой\инструментами...
     
     
  • 7.41, пох. (?), 12:14, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Сейчас даже на "одноногом проде"(ТМ) проще k3s "в одну команду (Ну, вы
    > её знаете - curl|sudo...)"

    вот за это вас и не любят.

    а компостер позволял все свое носить с собой, сравнительно компактно и без лишних торчащих концов. Но увы, все что попало в руки покойной docker inc имело предсказуемый конец.

     
     
  • 8.45, User (??), 12:40, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нуу да , но нет И условный k3s можно с собой в закрытом контуре без дост... текст свёрнут, показать
     
     
  • 9.48, пох. (?), 12:52, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    вот если там компостер - то главное в этот момент остановиться, инструкцию закры... текст свёрнут, показать
     
  • 6.40, пох. (?), 12:12, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    тут две проблемы - во-первых, компостер зохаван и ... брошен. (Ну как и все что попадает в руки этих деятелей, покрутить, пару раз переделать и бросить, убежав за новым каким-то фуфлом) Т.е. это недоделок, который никогда доделан и не будет. (Как и сам докер, за пределами того что обеспечивает им приток деньгов - т.е. виндовый vm-based pro)

    При этом он пока был живой - без конца переделывался и сам с собой несовместим, поэтому выработал у профессиональных борцов с такими вот самостоятельными разработчиками и их заброшенными через два года продуктами четкую рвотную реакцию.

    Во-вторых оно не масштабируется. И если у тебя там что-то чуть более сложное чем десяток строчек - переносить это в какой-нибудь упаси Б-же попенштифт или не к ночи будь помянут k8s будет мучительно больно.

     

  • 1.3, Аноним (3), 08:55, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Уязвимость вызвана обращением к уже освобождённой памяти (use-after-free),
    > Проблема позволяет обойти sandbox-изоляцию

    Сишка настолько дыр... ОЙ! - мощный язык, что плевать ему на эти ваши сэндбоксы.

     
     
  • 2.4, Re4son (ok), 08:59, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +6 +/
    это как ругать экскаватор, а не экскаваторщика, за то, что он пока копал -- перебил водопровод.
     
     
  • 3.6, User (??), 09:23, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Тут скорее болгарка об одной ручке без защитного кожуха, с однокнопочным включением и покоцанным диском. Можно работать? Можно. Можно добиться результата, аналогичного использованию _нормального_ инструмента? Конечно.
    Но рано или поздно (Скорее - рано) даже самый суперчудомастер окажется в, гм, интересной ситуации. Виноват ли в этом такой вот инструмент - которым _можно_ добиваться желаемых результатов - ну я даже и не знаю. Тут каждый сам для себя решает - если организация за него с какими-нибудь "Пять шагов к безопасности" заранее не подумала.
     
     
  • 4.23, bOOster (ok), 10:35, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Болгарку так-же пользует либо дурак, либо знающий человек. Дурак само собой последствий использования болгарки без кожуха не представляет.
    Поэтому для недопрограмистских дурачков и появляются языки типа Раста - в которых особо думать о последствиях не нужно, по словам этих же недопрограммистов.
    Хотя выход за пределы массива это частая проблема, но далеко не самая проблемная в целом.
     
     
  • 5.24, Анонимусс (-), 10:45, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > для недопрограмистских дурачков

    Пока что "недопрограмистские дуpачки" на сишечке продолжают лепить дырени с выполнением произвольного кода. Причем это не зависит от проекта, вот в соседней новости про гимп такое же выполнение произвольного кода из-за луДших погромистов эвэр.

    > но далеко не самая проблемная в целом.

    Ну да, ну да))

    Linux Kernel
    cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
    Memory Corruption 2735
    Overflow 365
    Все остальные в сумме - 51 :)
    Да, "не самая проблемная"))

     
     
  • 6.26, bOOster (ok), 10:54, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну да, ну да))
    > Linux Kernel
    > cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
    > Memory Corruption 2735
    > Overflow 365
    > Все остальные в сумме - 51 :)
    > Да, "не самая проблемная"))

    Ты отлично показал свою недопрограммистскую сущность в целом. Ориентироваться на количество багов. А не их актуальное влияние на результат выполнения кода и его безопасность.
    90% всего этого "счастья" выявлено посредством аудита, и использовать многие эти уязвимости в реальности нельзя. Они потенциальные.

     
     
  • 7.33, Анонимусс (-), 11:10, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  Ориентироваться на количество багов.

    Не на количество багов - их на порядки больше, а на количество CVE.
    На минуточку, это разные вещи. Но откуда "настоящему сишнику" об этом знать)))

    > использовать многие эти уязвимости в реальности нельзя. Они потенциальные.

    Ахаха, "ваши уязвимости не уязвимости".
    Ладно, давай заканчивая позориться, мы все уже поняли какой ты бракодел и 6ыdloкодер.

     
  • 5.28, User (??), 10:59, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Болгарку так-же пользует либо дурак, либо знающий человек. Дурак само собой последствий
    > использования болгарки без кожуха не представляет.
    > Поэтому для недопрограмистских дурачков и появляются языки типа Раста - в которых
    > особо думать о последствиях не нужно, по словам этих же недопрограммистов.
    > Хотя выход за пределы массива это частая проблема, но далеко не самая
    > проблемная в целом.

    О! Бывалый? )
    А тут ниже жаловались, что повывелись НАСТОЯЩИЕ-то программисты - а вот гляди-ж ты - на месте. Хоть болгаркой без кожуха, хоть сишкой хеллврот (Но тут уже возможны варианты, если промпт неправильный...), хоть комментом по супостату!
    ... пока такие люди в стране советской есть!(Ц)

     
  • 3.9, Аноним (3), 09:42, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > это как ругать экскаватор, а не экскаваторщика, за то, что он пока копал -- перебил водопровод.

    Новые перлы от местных мастеров аналогий. 🤦 А чего про забивание гвоздей микроскопом не упомянули?

     
  • 3.22, Аноним (22), 10:25, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > это как ругать экскаватор, а не экскаваторщика, за то, что он пока копал -- перебил водопровод.

    Старое доброе "чтобы не было ошибок - не делайте ошибки".

     

  • 1.5, Аноним (5), 09:10, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Уязвимость вызвана обращением к уже освобождённой памяти (use-after-free)

    Хм... Звучит как... Ну вы понели. Как характерная особенность одного хорошо известного всем языка. В программах на этом языке уязвимости такого рода выявляют по пачке в минуту. Любопытный факт: аббревиатура CVE уже включает в себя полное название этого языка, и даже две лишние буквы остаются. А вот еще любопытный факт: уже 50 лет подряд говорят, что язык не виноват, просто народ не тот^W^W^W программисты ненастоящие. Вот уж да: за 50 лет ни одного настоящего программиста не нашлось.

     
     
  • 2.7, User (??), 09:25, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но-но-но! Подождите часок - и тут целый перечень НАСТОЯЩИХ наберется.
     
  • 2.8, Аноним (8), 09:41, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В таком случае непонятно почему безопасные языки, типа ржавчины, компилируется в еще менее безопасный чем Си язык ассемблера.
     
     
  • 3.13, Аноним (12), 09:49, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если так думать - то ещё ниже уровнем электроны так вообще небезопасны, убить могут. АдОвайте код ментально у себя в голове запускать, так же безопасно...
     
  • 3.14, Аноним (3), 09:50, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > почему безопасные языки, типа ржавчины, компилируется в еще менее безопасный чем Си язык ассемблера

    Где ты эту чушь вичитал? У Раста бэкенд - LLVM, и именно его IR, а не "язык ассемблера" переводиться в машинные коды.

    > В таком случае непонятно

    Даже если бы там был конкретно ассемблер в качестве промежуточного представления - фундаментальное различие было бы в том, что он не писался бы вручую. Что тут непонятного?

     
     
  • 4.18, Аноним (8), 10:03, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > У Раста бэкенд - LLVM

    Он же на небезопасном языке написан?

     
     
  • 5.19, Аноним (3), 10:06, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да, как и ядро ОС. 🫡
     
  • 5.30, Аноним (-), 11:01, 09/10/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.10, похнапоха. (?), 09:45, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну если это такой плохой ЯП, что ты даже боишься упоминать его название, как ботоксный дед имя одного ныне покойного деятеля, тогда почему use-after-free чиниться не сменой ЯП, а просто переписыванием кода на этом же самом ЯП? Из миллиардов строк текста, написанных на этом ЯП - use-after-free появляется не везде и не всегда, то есть дело не в ЯП, а в людях!
     
     
  • 3.16, Аноним (3), 09:56, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > почему use-after-free чиниться не сменой ЯП, а просто переписыванием кода на этом же самом ЯП?

    Очередной горе-эксперт не видит разницы между борьбой с симптомами и борьбой с самой болезнью. Сменой ЯП оно не просто чинится - оно устраняется на корню.

     
  • 3.21, Аноним (22), 10:23, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Из миллиардов строк текста, написанных на этом ЯП - use-after-free появляется не везде и не всегда, то есть дело не в ЯП, а в людях!

    Нет, дело именно в ЯП. Потому что если дать ТЕМ ЖЕ людям нормальный язык, что use-after-free внезапно, больше появляется.

     
  • 3.46, Аноним (43), 12:44, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > имя одного ныне покойного деятеля

    Чисто юридически, правильно делал, чтобы его же по судам не затаскали. Просто достаточно упомянуть имя и уже можно подавать иск за клевету, а дальше дело "экспертизы". Конечно,  но "кто же его посадит", вот и от греха подальше он не употреблял ни чьих имен, тупо рекомендация настоятельная адвокатов, хотя по психотипу и характеру ему это очень хотелось, он не то, чтобы имя, но и вслед еще трех этажный мат готов был высказать "на всю страну".

    пс: он один, даже в сортир не ходит, сами знаете почему :)

     
  • 2.11, anonymous (??), 09:45, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот уж да: за 50 лет ни одного настоящего программиста не нашлось.

    А как же ваше любимые языки с управляемой памятью - java или python. Они ведь на си написаны. Если вы считаете что ни один программист не может справиться с си, и ошибки - неустранимое свойство самого языка, то почему вы призываете использовать другие языки, написанные на си.

     
     
  • 3.15, Аноним (12), 09:56, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Лично я призываю использовать C#, у него давно ничего под капотом него кроме самого C#.
     
  • 3.17, Аноним (3), 09:58, 09/10/2025 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 3.31, Анонисссм (?), 11:03, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А как же ваше любимые языки с управляемой памятью - java

    Если ты и вправду не понимаешь, объясню разок: jvm пишут профи, а сами проги на java среднячки (коих 95%). В итоге средний код на java всё равно безопаснее получается, потому что управление памятью писали профи, а среднячки только клей )

     
  • 2.29, Анонисссм (?), 11:00, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот уж да: за 50 лет ни одного настоящего программиста не нашлось.

    я тебя плюсанул и поржал, спасибо. Но тут ты неправ, есть же всякие postfix-ы и qmail-ы

     
     
  • 3.35, Аноним (35), 11:33, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Мы говорим про тот самый qmail, в котором в 2020 году
    "показали возможность эксплуатации уязвимости в почтовом сервере qmail, известной ещё с 2005 года (CVE-2005-1513), но остававшейся неисправленной, так как автор qmail утверждал о нереалистичности создания работающего эксплоита"
    opennet.ru/opennews/art.shtml?num=52991
    ?

    Отлично бекдор жил 15 лет!

     

  • 1.20, бочок (??), 10:06, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > score 10 из 10
    > для эксплуатации уязвимости атакующий должен иметь возможность отправки запросов к СУБД Redis, допускающей выполнение пользовательских Lua-скриптов.

    Тьфу...

     
     
  • 2.32, нах. (?), 11:07, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    дык это практически любой экземпляр, который ты сумеешь найти в этих ваших интернетах.

    Там ненужно-lua со времен версии 2, по-моему.

     

  • 1.27, Аноним (-), 10:58, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Воистинну, "C in CVE stands for C language"
    Дыpяшка делает дыpявым все к чему имеет хоть какое-то отношение.

    Вот узявимости "в LUA":
    CVE-2025-49844 - deps/lua/src/lparser.c
    CVE-2025-46817 - ‎deps/lua/src/lbaselib.c
    CVE-2025-46819 - deps/lua/src/llex.c
    CVE-2025-46818 - src/config.c, src/function_lua.c, ..., ну вы поняли :)

    А какие отличные были фиксы!
    github.com/redis/redis/commit/fc9abc775e308374f667fdf3e723ef4b7eb0e3ca

    - if (cast(unsigned int, key-1) < cast(unsigned int, t->sizearray))
    + if (1 <= key && key <= t->sizearray)

    Опять бедняги не смогли правильно посчитать размер буфера.
    Причем они выше еще с типами нафакапили. Что не удивительно, ведь этот недоязык просто молча кастит инты туда-сюда.

    github.com/redis/redis/commit/3a1624da2449ac3dbfc4bdaed43adf77a0b7bfba

    - return (ls->current == s) ? count : (-count) - 1;
    + return (ls->current == s) ? count + 2 : (count == 0) ? 1 : 0;
    И опять не смогли! Да что же такое?!

     
     
  • 2.38, Аноним (38), 11:46, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Тут главное помнить: сделал ошибку в Си на 10 баллов - неосилятор просто.

    Но вот если тебе не нравится синтаксис других языков где такую ошибку сделать гораздо труднее - ты передовой борец со всем плохим, а вовсе даже не неосилятор, неспособный выучить современный язык с какими-то неведомыми концепциями вроде "типы" и "проверка компилятром."

     
     
  • 3.42, Аноним (42), 12:21, 09/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В go синтаксис такой же. Но там почему-то подобные ошибки сделать не получится. Молча типы не приводит и в ручную память считать не нужно.
     

  • 1.44, Аноним (-), 12:38, 09/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > уязвимость вызвана обращением к уже освобождённой памяти
    > проблема позволяет обойти sandbox-изоляцию
    > исследователи продемонстрировали рабочий эксплоит
    > ошибка оставалась незамеченной на протяжении 13 лет

    Просто шикарно! Сразу видно - типикАл сишечка :)
    Зачем нужны хитрые анбешные бекдоры, если можно "просто вот совсем ваще случайно" не проверить на null переменную?)))

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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