.рубик

Страх и ненависть к шарообразному виду сообщений в дестопной телеге

Где-то три-четыре дня назад в бету десктопной телеги (tdesktop, оффклиент под десктоп, на qt) прилетел апдейт...
Который сделал из немного скругленных углов у сообщений - просто один полукруг.

То есть, раньше у баббла сообщения было два немного скругленных угла, а теперь там огромная дуга (см прикрепленную картинку).

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

Вполне ожидаемо от таких изменений офигел не я один, и народ пошел на гитхаб в репу телеги с резонным вопрос "ЧЗХ?": раз, два, три, четыре...
Причём людей, которые защищали бы новое скругление - там не отметилось)

Самое смешное, что в 2016 уже делали такие же круглые сообщения, и это, внезапно, тоже никому не понравилось (ишшю из 2016 состоит из двух этапов: 1. обновиться; 2. страдать)
Если покопаться в старом треде, то можно найти очень интересные вещи: например, скрипт для GDB, используемый для фикса готовых сборок телеги в рантайме.
В общем тред интересный, советую глянуть :)

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

И в конце-концов пришел какой-то гений (DragoonAethis) и сделал PR с добавлением "экспериментальной фичи", возвращающей всё взад.

В общем, Дуров: верни квадратные сообщения!!!1

Никогда не используйте личку в телеге, как склад логов.

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

Workaround - складывать всё важное в отдельные каналы/супергруппы.
А очень важное - вообще не хранить только в телеге, а бэкапить ещё куда-нибудь.

Чуть подробней, как это работает:
На все личные беседы (человек-человек, человек-бот, + сохраненки тоже считаются) и обычные группы (таких уже почти нет, обычно группа очень быстро апгрейдится до супергруппы) внутри телеги есть единый счетчик входящих и исходящих сообщений.
После того, как счетчик заходит за 1-3 миллиона сообщений (у разных людей по-разному) - телега перестает отдавать сообщения за произвольный промежуток времени.

Для каждой супергруппы и канала этот счетчик отдельный, поэтому для них проблема не так критична.

Проверить, "сколько сообщений уже наспамлено", можно через @ArynIDBot или @accountcountbot, отправив через inline сообщение в сохраненки.

Реф баги в багтрекере телеги, там ещё немного подробней про проблему на английском: https://bugs.telegram.org/c/19148.

Алсо, ещё в комментах у Ly (от самого Ly, в общем-то, с ссылкой на девтим телеги) вычитал, что
1) удаление сейчас не помогает. Там именно по айдишникам удаляет.
насколько понимаю, просто удалить мусорные сообщения, если их уже много, не поможет.
2) это, внезапно, тянется ещё с ВК.
(какая связь телеги и вк с точки зрения кода не представляю, и думать об этом страшновато)

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

Статья не самая свежая, но написана хорошо и читается легко. (а ещё там есть смешные мемы!)

Категорически рекомендуется к прочтению.

Случилась у меня ситуация - человек закоммитил в репу, однако перед этим переел грибов не настроил нормально гит/ вскод, и во всём коде в репе LF заменился на CRLF.

А потом человек сделал ещё два коммита, уже по файлам с CRLF'ами.

Ситуацию надо исправлять, соответственно, в итоге хотелось бы иметь все те же коммиты, но без CRLF'нутых файлов.

Каким путем пошел я (абсолютно ебанутый):
1. Берем коммит, делаем на него
git checkout
2. Фиксим crlf в файлах. Я делал так: grep -r -l '\r' . | xargs sed -i '' -e 's|\r$||'
3. Делаем git add && git commit --amend, чтобы получить новый коммит, но уже без дерьма.
4. Записываем хэш получившегося коммита.
5. Повторяем для всех коммитов до последнего.
6. Берем перый коммит, и делаем git cherry-pick всех последующих исправленных коммитов.
8. Перемещаем ветку на новую историю.
9. Форспуш.
10. ?????
11. Профит!

Вообще, вместо cherry-pick, вероятно, достаточно было бы обычного ребейза, но не уверен.
Также, возможно, можно собрать какую-то хитрую команду для гита (жду предложений в комменты :D), которая бы проходилась по коммитам и сама их исправляла, но способ выше был более прямолинейный и простой.

upd: в комментах подсказывают, что таки можно сделать нормально, через git filter-branch: https://stackoverflow.com/a/2466992

И не забываем выдать человеку пиздюлей правильные настройки ide/git'a, чтобы такого больше не случалось.

Небольшая питонячья радость.

Либа asyncer от небезизвестного tiangolo.

Это очень маленькая библиотека на 4 функции, которые чутка упрощают жизнь в async-мире.

Собственно, список фунок:
1. .runnify. По факту, просто asyncio.run, но с корректными типами и возвращаемыми аргументами.
2. .create_task_group / .soonify - на мой взгляд, самое полезное, что есть в либе. Позволяет легко и без бойлерплейтов запускать одновременно пачку тасков на выполнение. Чуть подробней - в доке. Такую же фичу для for-циклов обещают в 3.11 или 3.12 питоне, кажется, но пока живем так.
3. .asyncify / .syncify - обертки для запуска синхронного кода из асинхронного, и наоборот. (нет, syncify это не совсем runnify, есть отличия)

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

И ещё годных статей на хабре, на этот раз про нетрадиционные способы вытаскивания зашифрованной прошивки из SPI флешки, подключенной на QN9022 (и в целом серии QN902x) из сяомишного чайника.

Фулл: https://habr.com/ru/post/663312/

Веселая история от гитхаба.

Кто-то достал oauth-токены для гитхаба из двух third-party приложух: heroku и travis-ci, а потом качал приватные репы

https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/

tldr: гитхаб обнаружил, что 12 апреля какие-то чуваки сперли ouath-токены для гитхаба у двух приложух-интеграций, после чего начали выкачивать приватные репо из организаций, видимо, чтобы потом доставать оттуда креды и расширять область атаки - к ним в npm инфру заходили с ревокнутым AWS api ключем

Гитхаб ещё 22 числа раскидал письма тем, по кому прошлись точно, и собственно сейчас начал рассылать письма тем, по кому пройтись могли.

В телегу завезли новую обнову (офф патчноут)

В обнове - кастомные звуки уведомлений, произвольное время мута (вот это приятно), реплаи в форвардах (тоже хорошо)...

И скромно, без акцента - добавили ботам возможность рисовать html-странички прямо в клиенте телеги.
Попробовать эту штуку предлагают в @DurgerKingBot
(Дуров, кстати обещал и клялся, что не будет рекламировать фастфуд, а тут такая неприкрытая реклама).

В комментах к посту с обзором этой фичи в канале нецифровой экономики увидел, что новая фича, по сути, скопирована у китайцев из их вичата.

И с точки зрения безопасности к этой фиче очень много вопросов, кстати - ждем 0day в хроме через телегу...

Вообще, нельзя не заметить, что из телеги уже который год пытаются вылепить продукт куда больший, чем просто мессенджер - то ли новый веб (3.0? 4.0?), то ли ещё что.

«Никогда такого не было, и вот опять» (c).

Пару дней назад hashicorp внезапно ограничил доступ к cloud-версии терраформа для пользователей из РФ - конкретней, с российских IP.
Конкретней - https://portal.cloud.hashicorp.com и https://app.terraform.io возвращают пустые страницы с ошибками.

Дискуссия у них на форуме: https://discuss.hashicorp.com/t/problems-with-access-from-ru-region/35281/2

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

Ответ на вопрос от санитара полугодовй давности, кстати: работает второй вариант.

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

Дока из pydantic.Field, правда, пока не подтягивается, как и наоборот - дока из питоновского коммента в схему.

В питонячей либе celery нашли забавную CVE, причем я тоже думал о подобной проблеме когда делал таск на кубок CTF России, и как оказывается недокрутил потенциальную CVE.

Давайте попробую рассказать про что там.

Celery - реализация очереди задач для Python. Основной функционал - возможность создавать и планировать задачи (единица исполнения кода), которые потом могут быть выполнены на другом воркере.

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

Чтобы доставить информацию о задачах на другие машины нужно использовать какое-то внешнее хранилище/брокер, например redis или rabbitmq.

Также celery позволяет хранить информацию о результатах выполнения задачи из коробки в так называемых result backend’ах. Это опять же может быть redis/memcached/бд. [1]

Вопрос, который я задал себе при составлении таска около месяца назад - «а что если мы можем повлиять на хранилище тасков (брокер) или хранилище результатов ?»

Может показаться что такое маловероятно, но достаточно популярный вариант брокера/бэкенда — redis (k-v хранилище).
При этом многие приложения могут использовать редис для кэширования или позволять пользователю хранить там свои данные.
Представить что для простоты деплоя люди будут использовать один и тот же редис для кэширования, хранения данных и celery достаточно легко.

Люди, которые интересуются безопасностью, могут быстро придумать вектор — сериализация (способ кодирования/декодирования объектов в рантайме в байты).

В питоне для сериализации есть очень мощный, но страшный инструмент — pickle. Pickle позволяет сохранить любой питоновский объект в байты, но несет by-design проблему безопасности — десериализовать можно любой объект с мета-поведением, из-за чего при десериализации может быть выполнен произвольный код. [2]

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

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

Именно эта идея легла в основу моей задачи на кубок CTF. [3]

А теперь про CVE.

Задача может упасть с ошибкой. Если результатом выполнения задачи будет исключение (exception), то celery честно положит эксепшен в result backend (как строку в случае JSON).

Если приложение захочет получить результат упавшей задачи, то celery прочитает информацию об исключении из брокера и попытается найти/создать тип данных, который задан в строке. [4]

Если немного детальнее, то в случае JSON сериализации в строке будет модуль, тип эксепшена и сообщение.

Передаем модуль - os, тип - system, сообщение - ls.

И celery честно попытается найти модуль os, и сделать вызов конструктора/функции system с аргументом ls.

Красивое RCE.

Fix

В фиксе [5] сейчас проверяется что полученный тип является наследником exception’a или класса ‘type’. Кажется звучит безопасно, но возможно супер-знатоки питона скажут что нет.

[1] https://docs.celeryproject.org/en/stable/getting-started/backends-and-brokers/index.html
[2] https://davidhamann.de/2020/04/05/exploiting-python-pickle/
[3] https://github.com/acisoru/ctfcup-21-quals/tree/main/tasks/web/json-config
[4] https://github.com/celery/celery/blob/c79d5c79c1c212b1f7e5036b7dca18568eae68de/celery/backends/base.py#L405
[5] https://github.com/celery/celery/commit/1f7ad7e6df1e02039b6ab9eec617d283598cad6b

Невероятно годная серия статей о разборе проприетарного формата карт для автомобильной навигационной системы.

Товарищ творит какую-то жесть в 010editor, я и не знал, что темплейты настолько широкие возможности дают.
Да и в целом материал с точки зрения подхода к форензике по данным, о которых ничего не известно - весьма хороший.

Первая часть и вторая часть.
Больше пока нет)

Очередной пост про весло.

На этот раз, правда, с болью: я запустил pacman -Syu, а весло или не весло, а сам пакман в результате потеряло часть системных файлов.
Их было достаточно много, при этом: например, bash или sudo просто не было, как таковых (они стали размером в 0 байт), а zsh ругался на:
zsh: error while loading shared libraries: /usr/lib/libcap.so.2: file too short
Очевидно, либа тоже была 0 байт.

В целом, из оставшихся доступных взаимодействий был маппинг весла по сети, был бинарь wsl.exe (есть ещё bash, но я проиграл в рулетку, и баш был тоже обнулен).

Какое решение всей это проблемы вышло по итогу:
Качается сама либа из пакетов арча:

https://archlinux.org/packages/core/x86_64/libcap/

Как-то её придется распаковать, а расжимать zstd скорее всего нечем - поэтому качается разжималка zstd отсюда

Либа распаковывается куда-нибудь, а дальше в проводнике открывается сетевой путь до tmp внутри весла \\wsl$\Arch\tmp, куда переносится либа.
Распаковать сразу в /usr из винды нельзя - винда ругается на пермишены (и правильно ругается кста).

Дальше фикшу либу, и можно уже заходить в шелл.
wsl -u root -e /bin/cp -r /tmp/usr /

Но всё веселье только начинается, надо ж ещё починить систему!

Логичней всего это делать через пакман, но увы - пакман тоже умер, поэтому по старой схеме - качаем https://archlinux.org/packages/core/x86_64/krb5,
распаковываем, накатываем поверх системы.

Ура, пакман появился, но починить всё нам будет мешать неработащий gpgme - его тоже придется накатить поверх системы.
(можно прописать "SigLevel = Never" в /etc/pacman.conf, но переустановить сам gpgme у меня всё равно не вышло - вылезли проблемы с либами).

Теперь gpg полностью работает, и можно наконец перенакатывать все пакеты: pacman -S --overwrite "*" $(pacman -Qnq)

Последним этапом можно попробовать поискать по системе мертвые файлы через лютый
find / \( -path '/mnt' -o -path '/sys' -o -path '/proc' -o -path '/dev' -o -path '/run' \) -prune -o -size 0c -print | grep -vE "lock|.gitkeep|__init__.py\$"
Но я у себя ничего не нашел.

UPD: покопался у себя в event viewer, и похоже, что причиной этому был OOM - весло попросило слишком много памяти, и винда убила виртуалку. pacman такое переживает достаточно плохо.

UPDx2: В комментариях подсказали, что восстановление после такого краша описано на арчевики - если вкратце, то половину действий можно упростить при наличии pacman-static (статической версии пакмана), или просто другого работающего арча, например, livecd, хотя в случае с веслом это сложнее. Also, мертвые файлы можно искать менее лютым find /usr/lib -size 0 - поскольку при обновлении пакетов из реп задевается только этот путь.

BTW, я форкал WSLHostPatch - https://github.com/Rubikoid/WSLHostPatcher, чтобы он пробрасывал только только один порт (захардкожено в коде. Можно сделать по-умному, с гуем и красивостями, но зачем.)
Ну и заодно впилил функцию eject'a патча, если он больше не нужен. Билдов правда нет, так что компилить придётся самому.

И, заканчивая пиар своего гитхаба - есть репо с дотфайлами, где в zshrc лежит ещё пара приколов с веслом, типа проброса SSH-агента от keepass'a внутрь весла.

К слову о resolv.conf - чтобы отучить винду от запихивания в весло своего DNS, а равно как и от автоматической генерации конфига при каждом запуске весла, надо прописать в /etc/wsl.conf сие:

[network]
generateHosts = true
generateResolvConf = false

И не забыть создать свой собственный resolv.conf, а то весло больно умное, и всё равно будет пытаться создавать его.

Можно также выключить генерацию host'ов, например.
А о других настройках можно тут почитать, можно, например, отключить проброс виндовых бинарей и сломать штуку из предыдущего поста)

Also, там же, но чуть ниже, описано, как настроить то, как весло будет потреблять память.

Ещё одна фича особенность WSL2, о которой знают не все)

Каждый раз, когда второе весло запускается - создается новая hyper-v сетка.
Соответственно, и айпишник самого весла, и айпишник винды в этой сетке каждый раз разный.

В итоге, если надо из весла сходить на какой-то сервис (например, иксы) в винде - надо сначала сначала определить этот айпишник
Наиболее простой и стабильный способ это сделать - вот такой вот однострочник для баша, который дергает виндовый netsh.
export REAL_WSL_ADDR=`netsh.exe interface ip show ipaddresses "vEthernet (WSL)" | head -n 2 - | tail -n 1 | awk '{ print $2; }'`

Есть ещё один вариант, через /etc/resolv.conf - но у меня весло стабильно криво поднимает DNS, поэтому конфиг резолва со статикой, и этот вариант не подходит.

После определения айпишника достаточно проверить, что сервис слушает не 127.0.0.1, а ip винды/0.0.0.0 - и всё, из весла можно на него сходить, других препятствий нет.

Небольшой upd к этому посту.

Как верно заметили в комментариях, этого же эффекта можно достичь через виндовую утилиту netsh:
netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.18.28.x
Работает на какой-то магии внутри сетевого стека винды. На мой взгляд, не так удобно - это лишние правила непонятно чего, которые непонятно где лежат и непонятно когда появятся/отвалятся. Да и чисто одной командой это обычно не сделать, всё же нужен нормальный скрипт.
Как пример, полный такой скрипт, который достает айпишник весла (он меняется периодически, да, это отдельная головная боль) и создает правила для WFP - тут.

Однако!
Народ придумал ещё аж два способа выпихивать весло бриджем в реальную сетку: раз, два (описание второго).

Собственно, весь тред issue с обсуждением проблемы тут: https://github.com/microsoft/WSL/issues/4150

В продолжение извращений - есть маленький бинарь на rust, который транслируется все вызовы себя в git в весле.

https://github.com/andy-5/wslgit

У него довольно узкий юзкейс, но вдруг кому-то пригодится)

Yet another WSL2 trick

Если хочется получить доступ к сервису, запущенному во втором весле из локальной сети, а не только с тачки с самим веслом - пригодится https://github.com/CzBiX/WSLHostPatcher.

Суть - когда внутри второго весла открывается listen tcp-порт - небольшой бинарь, маппящий всякие взаимодействия между виндой и веслом - wslhost.exe - начинает слушать этот же порт на 127.0.0.1 в винде, фактически выступая в роли tcp-прокси между виндой и веслом.
В итоге для пользователя появляется прозрачный доступ к порту, открытому в весле, но из локалки он не доступен.

Всё, что делает вышеупомянутая утилита - патчит в памяти этот бинарь, чтобы он открывал соединения не на 127.0.0.1, а на 0.0.0.0, слушая его на всех интерфейсах.

Нашел давно, но думал, что это достаточно узкая и частная проблема, а внезапно оказалось, что это не так)

Продолжая нерегулярную рубрику "а че там с бетой телеги"

Прилетела версия 3.0.5 beta, в которой в дефолтной синей теме поменяли цвет некоторых элементов.

Слева - было; Справа - стало

Вариант вернуть старую синюю тему: t.me/addtheme/h9soEq0wbHH4Co9k. Можно скачать себе файлом и поставить независимую версию)