Конец недели на работе - не повод расслабиться

[coolwolf0]

Корпоративная этика запрещает рассказывать о наших приключениях с айтишниками. Но вот пресловутый Оракл несомненно заслуживает публичного осмеяния.

Как вы уже наверное догадались, речь пойдёт о делах компьютерных, узкоспециальных, поэтому непричастную публику просим не напрягаться. Для остальных расскажу историю из жизни Очень Солидных Разработчиков. Не зря я кивал в сторону MySQL и прочих проверенных решений, когда выбирал базу данных для своего проекта. Но кое-кто надавил и вуаля: сидим под проприетарным Ораклом. Все обещанные им ништяки с полнотекстовым поиском оказались пшиком, и пользователи меня за это уже потихоньку клюют. А сегодня его глюки просто довели до белого каления. Мы все прекрасно помним те золотые деньки, когда программист должен был заранее выделять память под буфер, заботиться о его границах, дебагировать странные падения программы при переполнении этого самого буфера... И вот настал 21-й век, всё давно автоматизировано, написаны кучи библиотек и языков высокого уровня, искусственный интеллект скоро заменит художников и поэтов. Что же делает Очень Солидный Разработчик, который ещё и берёт за свой продукт немалые денюжки? Они пишут программу, в которой ... внезапно переполняется буфер. Да, она не падает от порчи кодового сегмента, но ошибка выдается совершенно феерическая: "передаваемая строка не заканчивается нулевым терминатором". То есть буфер ограниченного размера был передан в "подрезанном" виде и поэтому строка оказалась "неоконченной". Диагностировалось всё очень просто: после удаления из текста Job-а какого-то количества пробелов, эта тварь съела его за милую душу.

В плане самокритики должен признаться, что добавка текста в Job была тоже починкой бага (моего, не Оракловского). Но где я со своими игрушками, и где этот монстр с целым штатом дизайнеров, архитекторов и прочей заумной братии...

UPD: шёл 2018 год, а солидные корпорации всё падали и падали жертвой атаки ... текстовым сообщением

Comments

[the-drmad.livejournal.com]

Ну, это смотря сколько туда запихнуть. Подозреваю, что строку длиной 2^64 даже ойракул не переварит.

[coolwolf0]

Ага, я сейчас специально проверил последний коммит в Git-е - 1311 байтиков. Офигенный буфер для переполнения столь солидной системы. Для справки - речь идёт об их гуёвом интерфейсе под названием PL/SQL Developer. Он ли портачил или это уже на сервере бухалось, мне как-то плевать. Пейсатели херовы.

[the-drmad.livejournal.com]

Сорьки, автор удаленной репли - это была другая моя реинкарнация в ЖЖ. :)
Я хотел сказать, что 1311 байтиков это не всегда 1311 байтиков.

[coolwolf0]

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

[the-drmad.livejournal.com]

Внутреннее представление sql-текста может быть любым. Например, вместо ключевого слова - его числовой код + количество его повторов. Ну это в качестве грубого примера. В любом случае, суть еггога, видимо, не только в ограниченности статичного буфера, но и в структуре запроса. По крайней мере, лет 25 назад в некоторых версиях Лексикона были магические сочетания слов и знаков препинания, которые, например, мгновенно выкидывали его в Дос или ребутили систему. У меня даже коллекция лично найденных заклинаний была. Экспекто патронум и окулюс репарум. :)

[coolwolf0]

Увы, всё наверняка намного прозаичнее: этот грёбаный редактор запросов ещё до отправки на сервер "не шмог" переварить текст Job-а чуть-чуть более длинного, чем проверяли мартышки из QA.

[the-drmad.livejournal.com]

Как все скушно. Нет места в жизни детективам.