Skip to main content

Баги - страшные и ужастные

Рядовой программист при написании программы зачастую не особо задумывается об ошибках, которые волей-неволей, но закрадываются в код. Эти ошибки зачастую совершенно неочевидны и посему приживаются довольно надолго, как например этот 25 летний баг, доставшийся всем BSD системам по наследству от 4.2 BSD.

Еще некоторое время назад я совершенно не понимал зачем нужны все эти обновления, хотфиксы, патчи и пр., если в большинстве случаев ПО работает корректно. Однако информация (особенно ценная), будучи одним из самых востребованных товаров, зачастую страдает от недостатка внимания к ее защите. Вы думаете, что ваш компьютер полностью защищен? Тогда взгляните хотя бы сюда. С тем обилием нелицензионного софта на просторах нашей Родины велик риск поставить себе ОС или софт с уже "предустановленными" программами - троянами, вирусами, различными руткитами )), которые тут же примутся усердно работать, собирая информацию о вас и вашей деятельности и отсылая ее своим "хозяевам". Или же вы станете частью какого-нить ботнета. Перспектив масса, но ни одна из них особо не радует. Выход остается один - выдернуть сетевой кабель из системного блока, так как ни проприетарное ни открытое ПО не защищено от уязвимостей. Зачастую слышно, что для полноценной работы в Linux нужен инет, ну никак без него.... Для других ОС ситуация обстоит так же - все обновления ПО качаются из интернета.

Ну а если уязвима например библиотека? которая используется в сотнях государственных учереждений, университетов, частных и коммерческих организациях национального и международного масштаба? А если где-то до сих пор работает софт, саппорт для которого discontinued, и используется уязвимая версия? А если этот софт управляет вашей АТС или работает в сети сотовой связи и вы не сможете однажды набрать "03"? или управляет АЭС, расположенной неподалеку от вас? или...

В общем к чему я веду -"семь раз проверь, один раз закоммить". (C) Народная программистcкая мудрость.

Comments

  1. эээ а в чем смысл поста, так сказать основная идея? что писать надо аккуратно?

    ReplyDelete
  2. не просто писать акуратно, но писать с осознанием того, источником каких проблем может стать ошибка, понимая какая ответственность лежит на плечах. Проводить code review, пользоваться анализаторами кода, писать тесты. Одна из наиболее распространенных ошибок - ошибка переполнения буфера, использование которой злоумышленником, позволяет изменить точку выхода из стека и выполнить произвольный код. Посему нужно очень внимательно относиться ко всему, что получаем в качестве user input, будь то локально или по сети. Если это программа-сервер, то любой ввод получаемый от клиента следует интерпретировать как потенциально опасный, например. В частности много нареканий было по поводу Х сервера, который до недавнего времени требовал root привилегий для работы, а следовательно как только найдется уязвимость в нем, которую разработчики не успели пофиксить и выпустить патчи, то злоумышленник может творить с системой все что ему заблагорассудится, получив права суперюзера.
    Внимательно следует изучить опции любимого компилятора, так как они с каждым годом становятся все "умнее" и могут подобного рода ошибки отлавливать еще на этапе компиляции, либо генерировать код, который предотвращает выход за предел диапазона (о чем-то подобном не так давно разработчики Дебиан рассуждали). Внимательно относиться к ворнингам, - они не просто так выводятся, а для того, чтобы их читали

    ReplyDelete
  3. Вот кстати сегодня наткнулся, может пригодится
    http://habrahabr.ru/blog/development/42077.html

    ReplyDelete
  4. спасибо, мне сегодня как раз эту же ссылку на работе прислали ))

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

    ReplyDelete
  6. безусловно - это один из факторов. А представь, что ПО разработывается для государственного сектора каким нибудь институтом (например система голосования депутатов Верховной Рады "Рада"). И нерадивый исполнитель, не согласовав с заказчиком все возможные последствия и не проведя анализ рисков, внедряет это ПО, забыв упомянуть о том, что там используются сторонние компоненты... а потом в этих компонентах находят уязвимость и предприимчивый исполнитель продает кому-то свои услуги по эксплуатации этой уязвимости. Хотя в такой ситуации гораздо проще наверное оставить бэкдор... Ну да ладно, а то совсем уж апокалиптический пейзаж нарисовал )).

    ReplyDelete

Post a Comment

СООБЩЕНИЕ СПАМЕРАМ: прежде чем пытаться оставить ссылку на свой ресурс в комментарии, прошу обратить внимание на тег nofollow, которым они помечены и зря не терять ни свое ни мое время. А будете упорствовать еще и noindex поставлю