Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Lazytech, Вы писали:

L>>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Мне неизвестно о сколь-нибудь серьезных уязвимостях в текстовых редакторах, связанных с обработкой plain-text, но это не значит, что таких уязвимостей быть не может.

L>>Пардон, тогда файлы каких форматов вообще можно открывать без опаски? Только не будем о частных случаях вроде просмотра по F3 в Far Manager и прочих «железобетонных» просмотрщиках — это, как я по-дилетантски догадываюсь, вроде бы упрощает задачу по защите от зловредов.

KV>Про просмотрщик не знаю, но в фаровском редакторе с установленным плагином раскраски синтаксиса colorer, уже могут быть проблемы: http://sourceforge.net/tracker/?func=detail&aid=2360079&group_id=34855&atid=413324
у меня колорер регулярно выбрасывает исключение при просмотре разных текстовых файлов. там просто ужос сколько багов. правда, представить себе сплоит, нацеленный на far+colorer...

KV>Единственный ответ на поставленный вопрос, который гарантировано будет правильным всегда: "ни в каком", т.к. файл по сути является информацией, полученной из недоверенного источника, который (при наличии уязвимостей в обработчике его формата) может быть использован для компроментации системы.

кстати, выяснилась любопытная особенность маков. html переименованный в .txt маки в некоторых случаях распознавали как html и пытались выполнить. тоже самое произошло когда я послал коллеге с маком файл PoC_pdf.txt, представляющий собой сплоит pdf, набранный в "блокноте" и представляющий собой текстовой файл. моей фатальной ошибкой было то, что он начинался с %PDF- и утилита file распознала его как PDF и запустила pdf-просмотрщик. коллега заразился. дальнейшие эксперименты привели к тому, что file не опознает это как PDF, если туда всобачить %%%%%%%%%PDF-, а акробату это по фиг. то есть это уже можно открывать как txt по щелчку и использовать как реальный сплоит после переименования .txt --> .pdf

тоже самое относится и к предварительному просмотру разными программами, которые могут самостоятельно опознавать, например, скрипты. так же в гугле десктопе был баг в индексировании pdf, приводящий к возможности передачи управления на зловредный код и расширение файла не играло никакой роли. это мог быть и .txt -- коллега под вынью с гуглом десктопом открыл plain text в котором приводилось содержимое зловредного pdf. гугл десктоп тут же скомпроментировал систему.

так что к приложениям для _явной_ обработки документов я бы добавил и службы, которые обрабатывают файлы в фоне. ой, да... тут еще вспомнил. Clamav (антивирус) так же имел багу в парсере pdf и пытался найти pdf во всех файлах по сигнатуре %PDF-, которая согласно спеккам может быть и не в начале. самый популярный российский антивирус (не буду называть его имени) так же сканируя файлы может игнорировать расширение и распознавать их по контенту. а потому если в .txt записать скрипт, то антивирус _может_ интерпретировать его как скрипт, задействовав довольно сложный парсер не свободный от ошибок.


> в то время как для plain-text — их единицы.
гм, ну я что-то не помню уязвимость ни одного plain-text редактора. без подсветки синтаксиса. с подсветкой -- txt становится очень сложным форматом, который нужно парсить (а как еще иначе подсвечивать?!), а парсеры всегда источники багов.

KV>Поэтому, как уже сказали выше: лучше не париться по поводу безопасности того или иного формата, а строить защиту своей информации исходя из того, что атака возможна всегда, уделяя вопросам защите от тех или иных обработчиков форматов внимание, прямо пропорциональное их функциональной сложности и объективно оценивая риски, обусловенные возможными успешными атаками.

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