Что значит незащищенность кода на платформе win32?

Question

[Aleksey FRZ]

Вот цитата из книги Фленова.

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

Что за незащищенность кода ? Простыми слова если можно.

Answer 1

[Дмитрий Александров]

По простому. Незащищенность означает то что любая программа имеет доступ к "любой" области памяти, даже не своей. Т.е. сторонняя программа может залезть в память выделенную для другой программы и делать там что хочет.
Есть еще clr в ней эту проблему какбы решили путем вынесения исполнения кода в "виртуальную машину" и соответсвенно у каждой программы есть свой индивидуальный кусок которой больше никто тронуть не может.

Answer 2

[Ambrosian]

Это было давно и неправда.
Со времен еще Windows Vista уже вполне можно жить и без антивируса.

Под незащищенностью имеется ввиду - одна программа может иметь доступ к другой (к файлам данных, конфигурации и исполняемым и т.п.).

Комментарий Дмитрий Александров, насчет незащищенности Win32 по памяти - ошибочный.
У каждой программы Win32 (не путать с очень древним Win32s) - своя область памяти.

Comments

[Aleksey FRZ]

Как программа может иметь доступ к другой программе ?
Приведите пожалуйста пример.

[Ambrosian]

Aleksey FRZ, я уже написал.
пожую:
подменяешь исполняемый файл своим, или внедряешь свой код внутрь чужого файла (перезаписываешь содержимое)

[АртемЪ]

Aleksey FRZ,

Как программа может иметь доступ к другой программе ?

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

[Дмитрий Александров]

Ошибочно это да но именно из за нюансов слово любой я выделил кавычками =). Ответ нужен был простой поэтому и утрированно написал.

[Ambrosian]

АртемЪ,

Записать значение в память другой программы.

А вот с этого момента - поподробнее.

[res2001]

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

[Ambrosian]

res2001,

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

как?

Возможно нужны админские права

В Linux c админскими правами чего только нельзя сделать...

[dollar]

Не забываем про Meltdown и Spectre, хотя это относится больше к процессорам.

[Ambrosian]

dollar,

Не забываем про Meltdown и Spectre, хотя это относится больше к процессорам.

И потому - ко всем ОС.

[res2001]

Ambrosian,

как?

Вот так, например.

[Ambrosian]

res2001, это не имеет никакого отношения к слабой защите Windows или защите вообще.
Процесс добровольно (ну или по принуждению администратора) включил в себя DLL.

[VoidVolker]

Как программа может иметь доступ к другой программе ?

Элементарно: ReadProcessMemory WriteProcessMemory

[Ambrosian]

VoidVolker, ага.
только это не имеет отношения к вопросам защиты.
доступ - санкционированный

Answer 3

[АртемЪ]

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

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

Answer 4

[Saboteur]

Возможно имеется ввиду реализация winapi еще во временя линейки win9x, когда защищенной памяти как таковой не было. Там да, была уязвимость ОС, когда любая программа могла оперировать с системными ресурсами и памятью.
В линейке NT каждый процесс и его область памяти защищен.

Answer 5

[InterceptorTSK]

Ответов на этот вопрос очень много) Потому что вопрос сильно обобщенный.

Например можно ответить так: в вин32 дескриптор памяти написан плохо. В вин64 уже лучше.
Но для вин64 нужен 64-битный процессор. Отсюда все и лезет.
Если есть 64-битный процессор, то он имеет "в железе" например nx-бит. И 64-битный дескриптор написан как бы под него, если сильно притягивать заушы. Суммарно получается так, что код и данные разделены. И железо следит за этим. Т.е. нельзя запустить код из данных.
А на 32-битных системах это можно было сделать запросто, через ошибку переполнения. Т.е. вставляете исполняемый код в картинку, картинку в программку, и программкой запускаете код из картинки. Ранее во времена 32-бит на этом строились защиты массово, и ровно так же распространялись эксплойты массово.

В общем смысле 32-битные системы не имеют контроля исполнения кода. 64-битные уже имеют. Но под это дело нужна еще и вменяемая организация памяти. В современных версиях например win-64 это есть. Впрочем оно же есть во всех 64-битных системах насколько я помню. Реализация прикручена уже везде.