The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в Apache Struts стала причиной утечки персональны..., opennews (??), 10-Сен-17, (0) [смотреть все]

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


18. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –2 +/
Сообщение от dwfeemail (?), 11-Сен-17, 05:03 
Вижу следующие проблемы:
- криворукость сетевого администратора в организации
- отсутствие сетевого администратора в организации
- целенаправленная халатность

Если сказать Tomcat запускаться на 80 порту, то он стартанет, но 80 порт слушать не сможет по причине:
Failed to initialize component [Connector[HTTP/2-80]]
org.apache.catalina.LifecycleException: Protocol handler initialization failed
Caused by: java.net.SocketException: Permission denied

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

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

20. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от slezhuk (?), 11-Сен-17, 07:18 
Да что вы заладили root да root? Прав непревелигерованного пользователя, под которым запущен томкат вполне хватит, что бы получить доступ к данным, к которым есть доступ у веб сервера. В данном случае- доступ в бд на чтение.
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от лютый жабист__ (?), 11-Сен-17, 07:23 
>бы получить доступ к данным, к которым есть доступ у веб сервера

Фронтенд инициирует создание сессии, получает некий токен, с ним ходит в СУБД.

Сломав фронтенд можно максимум получить информацию из других АКТИВНЫХ сессий.

Это если думать не попой.

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

26. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от Анотоним (?), 11-Сен-17, 08:52 
>Это если думать не попой.

А зачем ты ею думаешь а не головой?

Сказано "в течении 2 месяцев скачали данные 143 миллионов американцев".  Ты полагаешь за эти два месяца эти сто сорок три миллиона американцев ходили на сайт этого бюро?
Явно же медленно незаметно сдампили БД.

Для этого не нужен root, и этому не помешает дополнительная "прослойка" между frontend и BD.

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

54. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от Ку (?), 11-Сен-17, 11:12 
Прослойка помешает.
Максимум вытянешь данные залогиненных пользователей и то если получишь токены из памяти.
Другое дело, что в сабже этого не было сделано и все(или почти) данные слили.
Это архитектурная недоработка в безопасности ифраструктуры.

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

55. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Ку (?), 11-Сен-17, 11:21 
К тому же в памяти можно хранить "сырые" токены и только в момент передачи их в БД сервис, дешифровывать по определенному алгоритму.
В этом случае даже получение такого токена из памяти ничего не даст, пока ты не разберешся как его дешифровать, ибо БД сервис не будет его принимать.
Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Анотоним (?), 11-Сен-17, 13:54 
Отличный подход: Понадеяться на прослойку/БД и писать плохой код!
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Ку (?), 11-Сен-17, 17:06 
Как вам удалось сделал такой вывод из сказанного мной?
Пишите хороший.
Прослойку это не отменяет.
Ответить | Правка | Наверх | Cообщить модератору

166. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Анотоним (?), 12-Сен-17, 10:07 
Зачем нужна прослойка при хорошем коде?
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от dwfeemail (ok), 11-Сен-17, 09:05 
> Да что вы заладили root да root?

Я человек простой - читаю текст новости и строго по нему спамлю в комментах.

Исключительно по тексту новости:
"Обе проблемы позволяют выполнить свой код на сервере, при этом если web-приложение выполняется в контейнере Apache Tomcat, запускаемом с правами root, в результате удалённой атаки может быть получен доступ с правами root."

Они первые начали :)

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

51. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от slezhuk (?), 11-Сен-17, 10:57 
Так в том то и дело, что в новости написано: "если web-приложение выполняется ... с правами root", но при этом нигде не написано, что у Эквифакса оно работает от рута. А все почему то прочитали это как: "Эквифакс не умеет в томкат и запускает его от рута".
На мой взгляд вина Эквифакса варьируется между "не умеют выбирать стек приложений" (apache struts известен большим количеством критических уязвимостей), если их поимели через CVE-2017-9805 и "не умеют патчится", если их поимели через CVE-2017-5638. К первому особо не докопаешься, потому что 0-day и такое может случиться с любым стеком технологий. Если второе, то тут конечно серьезнее. 2 месяца не патчить RCE - за такое надо наказывать -рублём- долларом.
Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Ан (??), 12-Сен-17, 11:41 
> Да что вы заладили root да root? Прав непревелигерованного пользователя, под которым
> запущен томкат вполне хватит, что бы получить доступ к данным, к
> которым есть доступ у веб сервера. В данном случае- доступ в
> бд на чтение.

Блин, тут говорят что подстановка байт кода в запрос. Теперь подумай достучаться до оси, инструментарий которой тебе известен, или подставить код, который вставит твой функционал в приложение, т.е. обратится к БД и сольёт тебе данные. Второе вообще не так тривиально и у хацкеров вызывает сегфолты и эксепшены, а не хеппи сливы.

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

29. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 09:01 
> Вина java здесь в том, что она просто-напросто не может творить чудеса

Кстати, может хоть вы мне объясните, почему Java-программисты испытывают затруднения с тем, чтобы, запустившись, сбросить права до нужных?

Java-то не может творить чудеса, но программист на то и программист ведь.

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

32. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 09:08 
Все они могут.
В новости линк же есть:
https://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_witho...

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

38. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от пох (?), 11-Сен-17, 09:44 
> В новости линк же есть:

этот линк как раз демонстрирует их полную беспомощность - от советов запускать через прокси, до совершенно безобразного сетуид-скрипта (который вообще неясно, зачем нужен - ну мышление жабоедов логике неподвластно), запускающего от рута шелл-скрипты томкэта (обосраться и не жить, вот это секьюрити)!

А понизить привиллегии после присасывания к 80-му порту, как делают все нормальные программы - нет, это не жабий метод.

Впрочем, действительно, и зачем? У сервера кредитного бюро хоть от какого пользователя его запусти, есть доступ к данным кредитного бюро. А больше ничего и не надо. Можно даже автосливалку этих данных с удобствами написать на жабе-ee, а чо, прикольно.


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

41. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 09:59 
> А понизить привиллегии после присасывания к 80-му порту,
> как делают все нормальные программы - нет, это не жабий метод.

Наилучшим, по их мнению путем, является старт Tomcat в качестве нативной для linux программы:
https://tomcat.apache.org/tomcat-9.0-doc/setup.html#Unix_daemon

Разве она не делает то, что вы описали -- понижает привилегии после присасывания к 80-му порту.
Вот цитата:
"jsvc has other useful parameters, such as -user which causes it to switch to another user after the daemon initialization is complete. This allows, for example, running Tomcat as a non privileged user while still being able to use privileged ports. Note that if you use this option and start Tomcat as root, you'll need to disable the org.apache.catalina.security.SecurityListener check that prevents Tomcat starting when running as root."

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

49. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 10:50 
> Разве она не делает то, что вы описали -- понижает привилегии после присасывания к 80-му порту.

jsvc конечно же делает то, что надо, вот только подход с jsvc не всегда применим как минимум из-за того, что не всегда допустимо демонизировать процесс средствами java, как это в нём делается.

Банальный пример: есть большой проект, в котором куча демонов, написанных на разных языках, которые общаются друг с другом через API. Для них используется djb's daemontools для унификации управления набором демонов. При этом подходе демоны должны запускаться в foreground. Но с jsvc этого сделать нельзя.

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

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

53. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от dwfeemail (ok), 11-Сен-17, 11:01 
Спасибо за разъяснение.
Честно говоря я не думал об этом.
И соглашусь с вами, что разработчики java могли бы для своего процесса предусмотреть сброс привилегий.

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

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

56. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 11:22 
> По всей видимости есть этому объяснение какое-нибудь, хотя я не могу найти таких объяснений.

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

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

58. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 11:38 
Мне почему-то кажется, что обязательность кроссплатформенности не является основной причиной. Я повторюсь, джава это атомный комбайн всего чего только можно и большинство из этого, если не все, кроссплатформенно. Уж задать эффективного юзеро могли бы состряпать.

Вобщем, решил спросить у типо шибко умных:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-Se...

если я там вопрос задал некорректно, можете присоединиться при желании :)

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

60. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 11:55 
> Мне почему-то кажется, что обязательность кроссплатформенности не является основной причиной.
> Я повторюсь, джава это атомный комбайн всего чего только можно и
> большинство из этого, если не все, кроссплатформенно.
> Уж задать эффективного юзера могли бы состряпать.

Да, это было бы здорово. Если найдётся когда-нибудь такой способ, я бы протолкнул его нашим явистам.

> Вобщем, решил спросить у типо шибко умных:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-Se...

core-libs-dev@openjdk.java.net ?

> если я там вопрос задал некорректно, можете присоединиться при желании :)

Корректно. Я пока послежу в режиме ro.

PS: Спасибо, кстати, за рассылку. Я вот с явой имел чисто потребительские отношения и не знал, куда писать с такими вопросами.

PPS: Подписался на gmane.comp.java.openjdk.core-libs.devel

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

62. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от dwfeemail (ok), 11-Сен-17, 12:02 
> core-libs-dev@openjdk.java.net ?
> PS: Спасибо, кстати, за рассылку.
> Я вот с явой имел чисто потребительские отношения и не знал,
> куда писать с такими вопросами.

Здесь все рассылки разрабов OpenJDK(читайте разарабов Java):
http://mail.openjdk.java.net/mailman/listinfo

> Корректно. Я пока послежу в режиме ro.

Уже задали следующий вопрос:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-Se...

что ответить я не знаю. Неужели в венде все так плохо с изменением эффективных юзеров? )))

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

64. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 12:15 
> что ответить я не знаю. Неужели в венде все так плохо с изменением эффективных юзеров? )))

ЕМНИП, в винде система прав сильно отличается от юниксовой. Там просто нет таких понятий.

С другой стороны, для сброса привелегий jsvc в винде что-то ведь делает. Я по исходникам прошёлся, но пока не смог найти этого места. Буду признателен, если Вы составите мне компанию.

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

66. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 12:21 
> С другой стороны, для сброса привелегий jsvc в винде что-то ведь делает.
> Я по исходникам прошёлся, но пока не смог найти этого места.
> Буду признателен, если Вы составите мне компанию.

В первом приближении я пока думаю, что они просто создают новый процесс)))
https://github.com/apache/commons-daemon/blob/6702852984689b...

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

69. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 12:34 
> В первом приближении я пока думаю, что они просто создают новый процесс)))
> https://github.com/apache/commons-daemon/blob/6702852984689b...

Вот-вот, как раз шёл сюда отписать то же самое.

Тут ведь фокус в том, что в виндах для определения прав процесса используется Access Token[0], который свой для каждого пользователя. Причём в отличие от Unix-сиситем, где можно на лету изменить uid/gid, процесс в винде, работающий с правами администратора, не может изменить токен текущего процесса [1].

[0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[1] https://salesforce.stackexchange.com/questions/15201/how-do-...

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

71. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 12:44 
В венде сейчас есть такое решение:
https://technet.microsoft.com/en-us/library/cc771525.aspx

Тут ключевое слово "сейчас".
В Java помимо кроссплатформенности есть еще такая бооольшая проблема как обратная совместимость.
Как вариант, плюсом к вашему предположению, разарабы java может сейчас и могут пользоваться RUNAS на венде, но на старых версиях венды это точно не работает и нет никакой гарантии, что будет работать в последующих версиях венды. А обратная совместимость это из-за чего на java сидят коммерцы.

[0] https://superuser.com/questions/973349/is-there-a-windows-eq...

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

76. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 13:00 
Ну, тут в общем-то обсуждается не фунцкия setuid, а скорее setuid bit. :)
runas позволяет именно что запустить программу из-под другого юзера, то есть по факту является windows-аналогом sudo/su. А вот изменить токен процесса после запуска возможности всё равно нет.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

82. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 13:15 
Гуд, значит стопроцентов дело в ведре.


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

215. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от Аноним (-), 18-Сен-17, 14:42 
Ваш пример не банальный, а глупый. Сишников не учат, что свой API не системные порты нельзя вешать? Может образование подтянуть, тогда и позориться не придется
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

67. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от пох (?), 11-Сен-17, 12:22 
> Разве она не делает то, что вы описали -- понижает привилегии после
> присасывания к 80-му порту.

jsvc-то делает, но как-то на удивление криво, нужна еще стройная система костылей и подпорочек.
А по той, первой ссылке - ад, треш и кабздец, чтобы без нее обойтись (совсем уж ужасными костылями).

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

Ну и от помянутых двух cve - ничем бы все равно не помогло - мой /root/.pron/ конечно, остался бы неукраденным, а таза банных - увы-с.

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

74. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 12:55 
> jsvc-то делает, но как-то на удивление криво,
> нужна еще стройная система костылей и подпорочек.

разъясните пожалуйста про костыли и подпорочки, мне для понимания надо

> Ну и от помянутых двух cve - ничем бы все равно не помогло
> - мой /root/.pron/ конечно, остался бы неукраденным, а таза банных - увы-с.

спасет корректная архитектура приложения.
Вот Ку объяснил:
http://www.opennet.ru/opennews/art.shtml?num=47170#26

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

80. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 13:11 
>> jsvc-то делает, но как-то на удивление криво, нужна еще стройная система костылей и подпорочек.
> разъясните пожалуйста про костыли и подпорочки, мне для понимания надо

Ну, чёткого определения костыля вообще нету, обычно эти слова произносятся в зависимости от того, насколько было уязвлено "чувство правильной вещи" комментирующего.

Но вообще понять его можно: человек видит, что для того, чтобы банально сбросить права после выполнения привилегированных операций, в JVM требуется аж целый супервизор и своя видоизменённая процедура запуска ява-машины. И человека от этого (естественно) трясёт.

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

81. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 13:15 
)))))
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 13:25 
А ведь вы правы. Многих после такого:
http://radikal.ru/fp/rfy4trkjz5uoa

начнет слегка потряхивать))))

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

88. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 13:36 
> А ведь вы правы. Многих после такого:
> http://radikal.ru/fp/rfy4trkjz5uoa
> начнет слегка потряхивать))))

Да ладно, это как раз-таки нормально. Тут хотя бы есть стопудово рабочий способ. :)

А вот я недавно бился со сборкой Boost и Racket: так там в сборочных сценариях строчки вида


CXX = g++ ${CXXFLAGS} ${OTHER_OPTS}

Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий. Причём в некоторых проектах, с которыми я сталкивался, ещё есть возможность вычленить эти места и заменить там g++ на $(CXX_SUBST), после чего выполнить CXX_SUBST=/usr/bin/g++-4.8 make -e, однако в вышеобозначенных двух такая хитрая мешанина из cmake/libtool, что у меня руки опускаются.

Вот от этого -- реально трясёт. А от jsvc не трясёт. Это ещё более-менее. :)

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

105. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от пох (?), 11-Сен-17, 18:12 
> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов
> разных версий.

вообще-то _правильно_ установленный "компилятор разных версий" умеет переключаться ключиком -V, задаваемым, банально, в cflags. В данном случае -V 4.8 Авторы boost не вполне виноваты в том, что современные gcc собрать так, чтобы этот ключик работал и ничего другое при этом не сломалось в дистрибутиве - отдельное удовольствие.

Но их детское удивление, что могут быть другие с++ кроме g, вообразить, конечно, можно.

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

117. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от Аноним84701 (ok), 11-Сен-17, 19:44 
>> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов
>> разных версий.
> вообще-то _правильно_ установленный "компилятор разных версий" умеет переключаться ключиком
> -V, задаваемым, банально, в cflags. В данном случае -V 4.8

Приветствуем крионавта :)

http://gcc.gnu.org/gcc-4.6/changes.html
> GCC 4.6 Release Series
> Changes, New Features, and Fixes
> Caveats
> The options -b <machine> and -V <version> have been removed because they were unreliable. Instead, users should directly run <machine>-gcc when cross-compiling, or <machine>-gcc-<version> to run a different version of gcc.
>

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

123. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от пох (?), 11-Сен-17, 20:07 
> Приветствуем крионавта ;)

ну я же предупреждал, что не так прямо все легко. До 4.7.2 код еще с нами, afair, просто отключен, и, к счастью, его присутствие нужно только в собственно /usr/bin/g{cc,++} - если не новый-модный дистрибутив, велик шанс что там еще установлено что-то совместимое.

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

109. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от Orduemail (ok), 11-Сен-17, 19:02 
> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий.

mkdir bin
export PATH="`pwd`/bin;$PATH"
ln -s /usr/bin/cool-c++-compiler ./bin/g++

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

112. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от Аноним (-), 11-Сен-17, 19:31 
>> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий.
> mkdir bin
> export PATH="`pwd`/bin;$PATH"
> ln -s /usr/bin/cool-c++-compiler ./bin/g++

Ну да. Ведь сделать "СXX ?= g++" отдельной строчкой сложно, пускай лучше пользователь мудохается с костылями.

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

124. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от пох (?), 11-Сен-17, 20:09 
> Ну да. Ведь сделать "СXX ?= g++" отдельной строчкой сложно, пускай лучше
> пользователь мудохается с костылями.

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

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

128. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от Анонимный Аналитек (?), 11-Сен-17, 20:47 
>> Ну да. Ведь сделать "СXX ?= g++" отдельной строчкой сложно, пускай лучше
>> пользователь мудохается с костылями.
> канешна - это ж надо сообразить, из какого места модной аутолибульной хрени оно выползает

Да не нужно гадать.
>>> так там в сборочных сценариях строчки вида
>>> CXX = g++ ${CXXFLAGS} ${OTHER_OPTS}
>> костыль с ln
> "СXX ?= g++" отдельной строчкой сложно, пускай лучше пользователь мудохается

Т.е. делать так нужно как раз в аутолибульной хрени. Или в генерированном симейком мейке.

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

144. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от Аноним (-), 11-Сен-17, 22:31 
> канешна - это ж надо сообразить, из какого места модной аутолибульной хрени
> оно выползает (передаем пламенный привет последним чудесам в области "изобретем симэйк
> с квадратными колесами, ибо ниасилили даже документацию на него дочитать

Похоже на описание meson'а, чтоли.

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

119. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 19:50 
>> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий.
> mkdir bin
> export PATH="`pwd`/bin;$PATH"
> ln -s /usr/bin/cool-c++-compiler ./bin/g++

О! А вот это мне в голову не приходило. Завтра попробую, спасибо. :)

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

218. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 22-Сен-17, 19:25 
>> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий.
> mkdir bin
> export PATH="`pwd`/bin;$PATH"
> ln -s /usr/bin/cool-c++-compiler ./bin/g++

Увы, это не помогло. Помог вариант с user-config для bjam.
Но на будущее этот костыль тоже буду иметь в виду. Пригодится для чего-нибудь. )

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

219. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от Orduemail (ok), 22-Сен-17, 21:08 
>>> Вот за такое хочется руки оторвать, когда у тебя в системе стоят несколько компиляторов разных версий.
>> mkdir bin
>> export PATH="`pwd`/bin;$PATH"
>> ln -s /usr/bin/cool-c++-compiler ./bin/g++
> Увы, это не помогло. Помог вариант с user-config для bjam.
> Но на будущее этот костыль тоже буду иметь в виду. Пригодится для
> чего-нибудь. )

Хм... Очевидно мало было только симлинк на другой компилятор подсунуть, надо было ещё что-то. Но если это интересно, я могу порекомендовать глянуть в гентушный скрипт gcc-config[1], он перенастраивает все симлинки system-wide, с одной версии компилятора на другую. Это может быть в образовательных целях полезно, чтобы понять какие пути вообще важны, ну и практически тоже: вероятно, этот скрипт можно перелопатить, чтобы он без рутовских прав делал то же самое, играясь с переменными окружения и симлинками.

[1] https://gitweb.gentoo.org/proj/gcc-config.git/

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

220. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 23-Сен-17, 13:26 
> Но если это интересно, я могу порекомендовать глянуть в гентушный
> скрипт gcc-config[1], он перенастраивает все симлинки system-wide, с
> одной версии компилятора на другую.

Хм. Перенастраивать все симлинки system-wide - это может быть и неплохо для последовательно работающего emerge, но на сборочном сервере такой фокус не прокатит: что, если начнут собираться одновременно два компонента, требующие разных версий тулкита gcc? Один или даже оба огребут. Но вообще да, посмотреть пути полезно. Я вижу, там надо ещё поправить путь к include-ам было как минимум. Но в любом случае спасибо. Хорошо знать, что можно и так, и эдак, и через плечо. Спасибо. )

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

125. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Аноним (-), 11-Сен-17, 20:10 
> Boost
> строчки вида

Это где это в boost такое? Сколько раз собирал его кастомным компилятором, никаких проблем.

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

129. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 20:52 
>> Boost
>> строчки вида
> Это где это в boost такое? Сколько раз собирал его кастомным компилятором,
> никаких проблем.

Это какая-то дремучая версия буста, на которую завязались ряд наших компонентов, и которая мне досталась от предшественника.

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

133. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от Аноним (-), 11-Сен-17, 21:20 
Старше 15 лет, что ли (или когда они bjam туда вкорячили)? Так и надо сразу уточнять, а то вон один тролль уже начал сочинять сказки про разработчиков буста, не знающих о существовании разных компиляторов.
Ответить | Правка | Наверх | Cообщить модератору

147. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от пох (?), 12-Сен-17, 00:21 
> уже начал сочинять сказки про разработчиков буста, не знающих о существовании разных
> компиляторов.

ну я рад услышать, что они хотя бы за пятнадцать лет догадались, но кому и пятнадцать-то лет назад могло придти в голову использовать гвоздем прибитое гнутое имя компилятора?

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

151. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 12-Сен-17, 01:07 
> Старше 15 лет, что ли (или когда они bjam туда вкорячили)? Так
> и надо сразу уточнять, а то вон один тролль уже начал
> сочинять сказки про разработчиков буста, не знающих о существовании разных компиляторов.

Хм. Мне думется, что ей лет 10-12, но bjam там кстати есть.

UPD: нашёл версию в факлике index.html: 1.43.0
Значит, 2013го года.

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

152. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +2 +/
Сообщение от Аноним (-), 12-Сен-17, 01:18 
Раз так, то он должен собираться bjam'ом, и компилятор можно задать через user-config: http://www.boost.org/build/doc/html/bbv2/overview/configurat...
Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

183. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 12-Сен-17, 15:24 
> Раз так, то он должен собираться bjam'ом, и компилятор можно задать через
> user-config: http://www.boost.org/build/doc/html/bbv2/overview/configurat...

Спасибо, попробую.

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

217. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 22-Сен-17, 19:23 
> Раз так, то он должен собираться bjam'ом, и компилятор можно задать через user-config

Спасибо! Собралось отлично с нужной версией компилятора! :)

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

106. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от пох (?), 11-Сен-17, 18:13 
> Но вообще понять его можно: человек видит, что для того, чтобы банально
> сбросить права после выполнения привилегированных операций, в JVM требуется аж целый
> супервизор и своя видоизменённая процедура запуска ява-машины. И человека от этого

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

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

141. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –3 +/
Сообщение от Аноним (-), 11-Сен-17, 22:00 
> не забудьте еще предусмотреть супервизор этого супервизора, а то оно умеет навернуться
> - впрочем, там, помнится, на роль этого чуда в штатных хауту
> назначен системде.

В нем все это сделано и даже достаточно прилично. В Linux есть такая штука - watchdog. Если нет аппаратного, можно программный использовать, в ядре есть такая фича, хоть это и менее надежно. Аппаратный лучше, можно и оба сразу.

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

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

214. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от freehckemail (ok), 16-Сен-17, 10:24 
> В нем все это сделано и даже достаточно прилично. В Linux есть
> такая штука - watchdog. Если нет аппаратного, можно программный использовать, в
> ядре есть такая фича, хоть это и менее надежно. Аппаратный лучше,
> можно и оба сразу.
>
> Системд обязан дергать вачдог, для доказательства что он не помер. Остальные процессы
> которые он мониторит обязаны дергать системду, чтобы доказать что живые. Получается
> нормальная иерархия проверок, корень дерева иерархии в лучшем случае вообще на
> железке.

Вот же феерический бред. Нет, ну надо же! *Аппаратный* вачдог для мониторинга работы *процессов*! :)

> В случае с аппаратным вачдогом система придет в нормальный вид
> даже при зависании ядра, поскольку железку не интересует причина по которой
> ее не обслужили вовремя.

Системдешники такие наивные теоретизаторы, аж слеза наворачивается. :)

А как же смена контекста в планировщике? Как же IO, как же сеть? :)

> А вот как подобие этого делают без системды и с какими допущениями...

А в мире без системды считается, что программы падать не должны, и если они постоянно падают -- то эти программы плохие, и их выкидывают. А supervise (в ваших терминах -- watchdog) используется в исключительных случаях для крайне ненадёжных программ, которые выкинуть не получилось в силу обстоятельств.

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

45. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 10:24 
Если я все правильно понимаю, то они это делают вот так:
https://github.com/apache/commons-daemon/blob/6702852984689b...
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

212. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от Аноним (-), 16-Сен-17, 02:28 
>[оверквотинг удален]
> этот линк как раз демонстрирует их полную беспомощность - от советов запускать
> через прокси, до совершенно безобразного сетуид-скрипта (который вообще неясно, зачем
> нужен - ну мышление жабоедов логике неподвластно), запускающего от рута шелл-скрипты
> томкэта (обосраться и не жить, вот это секьюрити)!
> А понизить привиллегии после присасывания к 80-му порту, как делают все нормальные
> программы - нет, это не жабий метод.
> Впрочем, действительно, и зачем? У сервера кредитного бюро хоть от какого пользователя
> его запусти, есть доступ к данным кредитного бюро. А больше ничего
> и не надо. Можно даже автосливалку этих данных с удобствами написать
> на жабе-ee, а чо, прикольно.

Т.е. по вашему это джависты сервер приложений на проде запускают? Сишник?

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

40. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от freehckemail (ok), 11-Сен-17, 09:59 
> В новости линк же есть

Спасибо, поржал. Особенно над suid-ником. Не, всё правильно: запускать-то из-под юзера можно будет. Правда, работать он будет под рутом, ну да пофиг же, кому какое дело!

Нет, правда, до такой феерической тупости ещё додуматься надо. :)

PS: И это в HowTo на wiki.apache.org :)

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

43. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 10:06 
Да, нет же.
Работать оно будет под непривилегированным пользователем:
http://joxi.ru/12M1MRlH41bZ82

Скажите где у меня ошибка в рассуждениях.

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

47. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 10:29 
Ваша ошибка в том, что я говорю о варианте с suid-ником, а Вы -- о варианте с jsvc.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 10:35 
Извините, я действительно не уточнил, что говорил про использование стартера jsvc

Если вам не сложно, прокомментируйте пожалуйста вариант с jsvc.
Насколько по вашему мнению такой подход корректен?
Можно ли лучшее решение найти?

Я, к примеру, считаю что лучше всего использовать вариант:

- A another way is to use Iptables to redirect Port 80 and 443 to user ports (>1024)

* /sbin/iptables -A FORWARD -p tcp --destination-port 443 -j ACCEPT

* /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 443 --to-ports 8443

* /sbin/iptables -A FORWARD -p tcp --destination-port 80 -j ACCEPT

* /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp --destination-port 80 --to-ports 8080

/sbin/iptables-save or /etc/init.d/iptables save

If you'd like "localhost:443" to also redirect to "localhost:8443", you'll need this command as well:

* /sbin/iptables -t nat -A OUTPUT -p tcp -o lo -destination-port 443 -j REDIRECT --to-ports 8443

Also note that if you have existing rules defined in your chains, you will need to make sure that the rules above are not ruled-out by another rule when using -A to add the above rules. For example, if you have an existing FORWARD rule that says "-j REJECT" than adding the FORWARD rule after it will have no effect.

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

52. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от freehckemail (ok), 11-Сен-17, 10:58 
> Извините, я действительно не уточнил, что говорил про использование стартера jsvc
> Если вам не сложно, прокомментируйте пожалуйста вариант с jsvc.

Прокомментировал в #49.

> Насколько по вашему мнению такой подход корректен?

Он корректен не всегда, потому что форсирует демонизацию процесса.

> Я, к примеру, считаю что лучше всего использовать вариант

Да, мы сейчас для наших явовских демонов так и поступили.

> Можно ли лучшее решение найти?

Я собственно в #29 и спрашивал, почему у явистов такие проблемы со сбрасыванием привилегий. Лучшего решения пока не нашли, что поделать.

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

46. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 10:25 
Вот ссылка на исходник, где они устанавливают id:
https://github.com/apache/commons-daemon/blob/6702852984689b...

Вы считаете, что они это делают некорректно?
Если так, то приведите пожалуйста свой вариант.

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

211. "Уязвимость в Apache Struts стала причиной утечки персональны..."  –1 +/
Сообщение от Аноним (-), 16-Сен-17, 02:26 
>> Вина java здесь в том, что она просто-напросто не может творить чудеса
> Кстати, может хоть вы мне объясните, почему Java-программисты испытывают затруднения с
> тем, чтобы, запустившись, сбросить права до нужных?
> Java-то не может творить чудеса, но программист на то и программист ведь.

Объясняю - никаких затруднений ибо java здесь абсолютно ну никаким боком. Да не их это зона ответсвенности. А чюдеса творит не java и не с, а человек. И портачат точно так же люди. А так хочется быть умным по определению, потому что с. И автоматом пинать тех кто не согласен. Довольно убогий подход. Вам не кажется?

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

31. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +1 +/
Сообщение от zanswer CCNA RS and S (?), 11-Сен-17, 09:05 
Эм, а какое отношение сетевой администратор имеет к root на сервере?
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

33. "Уязвимость в Apache Struts стала причиной утечки персональны..."  +/
Сообщение от dwfeemail (ok), 11-Сен-17, 09:14 
Ну, хорошо, замените "сетевой администратор" любым другим устраивающим вас текстом, который идентифицирует должностное лицо, ответственное за вцелом работоспособность операционной системы компьютера, на котором запущен сервер Tomcat.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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