Как пишут безопасные проги?

чтобы пользователь со стремящейся к нулю вероятностью сумел получить доступ

Пихнуть говнокод в контейнер.

как пишутся безопасные проги

securecoding.cert.org

На Java.

а если на плюсах? а то ява уж больно тормозная.

стоит почитать на досуге этот стандарт.

То-то в JVM столько критических уязвимостей находят.

Или еще иначе можно спросить - как находят уязвимости нулевого дня?

Изучение исходников, фаззинг.

Господа, а как пишутся безопасные проги?

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

Потому что JVM на C++.

А вот если бы JVM на JVM на Java-процессоре...

То есть на что нужно обратить внимание, чтобы пользователь со стремящейся к нулю вероятностью сумел получить доступ к возможностям программы, которые ему не разрешены?

Строго проверять все возможные пути выполнения программы. В том смысле, что программа должна работать при любых входных данных и состоянии окружения. То есть, если, например, у тебя задача: «прочитать два числа со стандартного ввода и вывести их сумму», то надо предусмотреть адекватную реакцию программы на ввод произвольной строки (без ограничений на длину и символы). Для Си ещё внимательно смотреть, чтобы не налететь на UB, а то компилятор может сделать совсем не то, что ожидаешь.

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

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

Зависит от критичности системы. Если в случае фэйла ущерб минимален, то тестирование и code review. Если же всё будет очень плохо, к этому добавляется формальная верификация.

Возможно ли написать уязвимое приложение на Java? Допустим вот наспор? :)

Неужели не выйдет? А наоборот написать неуязвимое на Qt/C++ если быть чуть осторожнее?

securecoding.cert.org

+1.

То есть на что нужно обратить внимание, чтобы пользователь со стремящейся к нулю вероятностью сумел получить доступ к возможностям программы, которые ему не разрешены?

Никаких логических допущений касательно любых входных данных. Валидация должна быть жэстачайшэй. Изоляции побольше. Понижать привилегии до минимально потребных во время выполнения (см. selinux, openbsd pledge).

то есть решение а-ля cat /dev/urandom > ./my_prog и ждать веселого поведения проги?

то есть решение а-ля cat /dev/urandom > ./my_prog и ждать веселого поведения проги?

В общем случае, да (если программа не имеет параметров и читает только стандартный ввод).

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

Для Си ещё внимательно смотреть, чтобы не налететь на UB, а то компилятор может сделать совсем не то, что ожидаешь.

Что такое UB? Undefined behaviour?

Возможно всё. Но сложнее :)

Господа, а как пишутся безопасные проги?

Через тестирование
/thread

А если прога на вход принимает файл конфигов? есть простой способ «по-умному» опции конфига мусором заполнять?

Что такое UB? Undefined behaviour?

Да. Иначе бывает http://kqueue.org/blog/2012/06/25/more-randomness-or-less/

есть простой способ «по-умному» опции конфига мусором заполнять?

Подсунуть вместо конфига бинарник тоже полезно. А самый простой способ — написать программу-генератор конфигов.

Возможно ли написать уязвимое приложение на Java?

Более чем. Посмотрите багтрекер томката, что ли.

А наоборот написать неуязвимое на Qt/C++ если быть чуть осторожнее?

А вы сначала дайте определение «неуязвимому» ПО. Только общее определение, без перечислений частностей аля неуязвимость к внешним атакам, защита от дурака и т.п. Вот я, например, не понимаю, что это за «неуязвимое» ПО такое, и считается ли оно все еще неуязвимом, если, к примеру вилку из розетки вытащить?

повторяй пока не перестанешь писать чушь: Testing can show that defects are present, but cannot prove that there are no defects.

Есть люди которые и на яве умудряются течь устроить.

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

марш читать книги, тупица. тестирование в TDD вообще не предназначено для выявления дефектов, оно предназначено для документирования и проектирования системы

Вот я, например, не понимаю, что это за «неуязвимое» ПО такое, и считается ли оно все еще неуязвимом, если, к примеру вилку из розетки вытащить?

Я, Василий Иванович, совершенно не понимаю, как это человеку, который путает ПО с программно-аппаратным комплексом, доверили в Development хавло раскрывать

Нет такого программного средства, способного доказать что дефекты отсутствуют.

Coq.

Господа, а как пишутся безопасные проги?

На хаскелле.

Тогда уж не на хаскелле, а под Эльбрус=)

Раз уж приплел сюда проектирование, иди читать книги сам, коль не знаешь, что написание тестов в TDD это этап разработки, который чуть ли не середина модели проектирования ИС, после анализа объекта и определение концепций, в которых, к твоему сведению, определяются структура ИС, потоки событий, сообщений и анализ рисков, по которому, к слову и происходит разработка в TDD.
Так что твой аргумент не засчитан, старайся дальше, и по возможность чуть более тоньше.

Господа, а как пишутся безопасные проги?

Представителем белой расы с прямыми руками и светлой головой. При отсутствии строгих дедлайнов.

огонь ответ)

только на конечном наборе факторов, что не совсем соответствует действительности.

есть простой способ «по-умному» опции конфига мусором заполнять?

Да. QuickCheck в Haskell, аналоги для других языков.

Нет такого программного средства, способного доказать что дефекты отсутствуют.

Есть.

2016 год на дворе

Обработчик потокового HD-видео тоже на яве предлагаете писать? =)

какой процент от написанного софта составляют обработчики потокового HD-видео?

Господа, а как пишутся безопасные проги?

На высокоуровневых языках и фреймворках, которые не позволяют совершать ошибок. Как базовый пример, C'шный strcat с переполнениями во все поля vs. C++ std::string::operator+ где такого быть не может в принципе. C++, впрочем, в этом плане решает далеко не все проблемы, хотя все не решает пока ничто.

В смысле: с одной стороны, есть всякие техники типа управления памятью, права доступа и пр., но с другой-то стороны - находят же ж как-то уязвимости нулевого дня.

Ортогонально. Где-то используются техники, где-то находятся уязвимости. Если мы говорим о коде, права доступа сюда никак не относятся, хотя есть много средств уменьшить последствия эксплуатации уязвимости не касающихся безопасного программирования, начиная с тех же банальных прав доступа, изоляции, виртуализации и сандбоксинга и заканчивая -fstack-protector и ASLR.

Или еще иначе можно спросить - как находят уязвимости нулевого дня?

Ты хотел спросить как находят уязвимости вообще. «Нулевого дня» это всего лишь мера распространения информации об уязвимости. Да просто читая код - простые небезопасные паттерны видны сразу, более сложные требуют кропотливого анализа. Помогают себе статическим анализом. Не без упомянутого fuzzing'а, это сразу по площади.

процентов 30.

«не верю»

Обработчик потокового HD-видео тоже на яве предлагаете писать?

Почему нет? C++ в этом плане, кстати, тоже просасывает. На GPU обработка видео работает намного быстрее, и C++ тут не поможет вообще.

FP

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

На ноль поделил.

0. нанимаем опытных разрабов без проблем первого рода

1. review большим количеством народу

2. «покрытие тестами»

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

4. Свечка в церкви. Еще одна в заднице того, кто накосячил в прошлый раз.

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

6. Оперативное исправление проблем, поддержка продукта.

Остальное в наши дни свою эффективность не доказало. Я тут не рассматриваю исключение человеческого до...неаккуратности и использование вместо языков VM, так как тут появляется кажущаяся возможность сэкономить на программистах, но тут баг вылезет в VM и всё равно будет бить по репутации продукта, да и не все человеческие ошибки VM исключит, а только самые нубские. Я не верю в решение этих проблем использованием какого-либо VM, разве что если получится потом пальцем на VM показать и вам это сойдёт с рук. Особенно если в VM добавляются еще какие свои наьивные библиотеки... Разработка ПО связано со сжатыми сроками. Баги, включая баги безопасности, - часть рисков. Если риски слишком велики - используйте указанные выше методы, и если таки вылез баг - оперативно исправляйте. И помните, если бы за баги в медицинском оборудовании, проводящие к летальному исходу, программиста, сделавшего ошибку, сажали на срок в тюрьму, или с программиста, уронившего своей ошибкой ракету, заставляли вернуть её полную стоимость, это не повысило бы безопасность, просто оборудование бы стоило столько, что никто бы никогда не смог его купить, так как было бы слишком мало желающих это делать. Поэтому это всегда компромисс и баланс. Errare humanum est.

не отличает «предназначено для проектирования и документирования» от «заменяет весь процесс проектирования и документирования»

кукарекает в Development

уходи

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

Господа, а как пишутся безопасные проги?

1) Не использовать C и C++
2) Если всё-таки использовать, то поучитесь у девелоперов OpenBSD. Но я думаю, что лучше просто не использовать.
3) Можешь писать на OCaml, или если хочешь ещё большего хардкора, на Coq, который генерирует код на OCaml или на ATS, который генерирует код на C, ещё есть Idris, но он пока не готов.

Чем сильнее в языке система типов, тем сложнее написать небезопасный код.

Возможно ли написать уязвимое приложение на Java? Допустим вот наспор? :)

Конечно. Можно вообще почти любое приложение на ней написать, и оно будет уязвимым, если найдётся дырка в JVM. Безопасность в яве только от одного класса уязвимостей — переполнения буфера, но есть же множество других. Просто одно это уже делает её значительно безопаснее C/C++.

А наоборот написать неуязвимое на Qt/C++ если быть чуть осторожнее?

«Чуть осторожнее» — мало. Нужно быть адово осторожным. Теоретически исходные коды на C/C++ без уязвимостей существуют, практически сделать так, чтобы твой код совпал с одним из них очень сложно.

Много способов. Улучшение качества кода: парное программирование, code review, статические анализаторы кода, использование более безопасного подмножества языка, конечно же знание классов уязвимостей и уделение особого внимания всем местам, где может возникнуть уязвимость. Проверка результата: юнит-тестирование, fuzzy-тестирование, пен-тестирование, награды хакерам за найденные уязвимости.