The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Примеры небезопасного кода на Java (java security limit)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: java, security, limit,  (найти похожие документы)
From: Stiver <wasm@wasm.ru.> Date: Mon, 16 Dec 2007 14:31:37 +0000 (UTC) Subject: Примеры небезопасного кода на Java Оригинал: http://wasm.ru/article.php?article=unsjav1 1. Класс sun.misc.Unsafe 2. Структуры виртуальной машины 3. Особенности версии 1.5 4. Применение на практике 5. Бесконечный final Как известно при разработке языка Java с самого начала делался упор на "безопасность" кода (так называемый "safe code"). Помимо всего прочего это означало отказ от указателей, работы с памятью и тому подобных низкоуровневых средств. Совсем отказаться правда не удалось, пришлось оставить лазейку, в первую очередь естественно для собственных классов. Но все, что использует Java Runtime, можем использовать и мы. В этой статье мы научимся писать небезопасный код на Яве и используем новоприобретенные знания для решения некоторых интересных проблем, которые штатными средствами Явы не решаются. Рассматривать мы будем только Sun'овскую виртуальную машину, по двум причинам. Во-первых она применяется наиболее широко и является своеобразным эталоном. Во-вторых до IBM'овской у меня руки еще не дошли, а больше никаких (реально использующихся) я не знаю. Все приведенные ниже примеры протестированы с Java 1.4.2_11 и 1.5.0_06. Предполагается что читатель достаточно хорошо разбирается как в Яве, так и в общих принципах программирования. 1. Класс sun.misc.Unsafe Малоизвестный класс sun.misc.Unsafe входит в комплект Sun Java Runtime начиная с первых версий. Как и все остальные классы в package sun.*, Unsafe не документирован, но имена (в большинстве своем нативных) функций, видимые при декомпиляции, говорят сами за себя. Явно присутствуют функции работы с памятью (allocateMemory, freeMemory,...), чтения и записи значений по заданному адресу(putLong, getLong,...) и некоторые более специализированные(throwException, monitorEnter,...). То есть в принципе все, что нам нужно. Правда так просто инстанциировать Unsafe не удастся. Единственный constructor - приватный, а в getUnsafe() проверяется загрузчик вызвавшего класса и объект возвращается только если класс загружен Bootloader'ом. В противном случае получаем SecurityException. public static Unsafe getUnsafe() { Class class1 = Reflection.getCallerClass(2); if(class1.getClassLoader() != null) throw new SecurityException("Unsafe"); else return theUnsafe; } К счастью существует еще внутренняя переменная theUnsafe, до которой мы можем добраться с помощью Reflection. Всю черновую работу соберем в один класс (назовем его UnsafeUtil), который будем расширять по мере надобности. public class UnsafeUtil { public static Unsafe unsafe; private static long fieldOffset; private static UnsafeUtil instance = new UnsafeUtil(); private Object obj; static { try { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); unsafe = (Unsafe)f.get(null); fieldOffset = unsafe.objectFieldOffset(UnsafeUtil.class.getDeclaredField("obj")); } catch (Exception ex) { throw new RuntimeException(e); } }; } Конечно можно просто внести UnsafeUtil в список загружаемых Bootloader'ом классов (указав путь в ключе -Xbootclasspath/a) и вызывать getUnsafe() в соответствии с замыслом Sun. Беда в том, что тогда все использующие UnsafeUtil классы также должны быть прописаны в bootclasspath'е (см. главу "5.3 Creation and Loading" в VM spec). Правда например package java.nio как-то ухитряется обходить это ограничение, но как именно пока не очень понятно. К тому же этот способ выходит за рамки "чистого" кода, так как требует дополнительных стартовых опций для виртуальной машины. Так что не будем мудрствовать и ограничимся чтением theUnsafe. В первую очередь нам понадобятся естественно операции референцирования и дереференцирования, ObjectToAddress и AddressToObject соответственно. public static long ObjectToAddress (Object o){ instance.obj = o; return unsafe.getLong(instance, fieldOffset); } public static Object AddressToObject (long address){ unsafe.putLong(instance, fieldOffset, address); return instance.obj; } С ними мы уже достаточно хорошо вооружены в техническом плане, не хватает только информации по внутреннему устройству Явы. Ее мы найдем в следующем разделе. Очень похожую реализацию кстати сделал Don Schwarz (http://don.schwarz.name/index.php?p=30). Это одно из очень немногих мест, где можно найти хоть какие-то примеры работы с классом Unsafe. К сожалению Don в свое время не оценил потенциал низкоуровнего программирования в Яве и остановился, сделав всего пару робких шагов. Мы же пойдем дальше. 2. Структуры виртуальной машины Теперь посмотрим, в каком виде виртуальная машина (версии 1.4) хранит данные в памяти. Поскольку Ява работает с классами и их инстанциями, то ими и займемся. Инстанция: instance_struct { 0 magic // всегда равен 1 4 class // указатель на структуру класса, class_struct* 8 ... // Дальше идут подряд переменные инстанции(то есть все которые не static), 12 ... // порядок пока не очень понятен, судя по всему в порядке объявления и 16 ... // обьекты перед примитивными типами ... } Переменные типа double и long занимают 64 бита, остальные по 32. В памяти инстанции выравниваются по 64-битной границе, дополняются при необходимости нулями. То есть по сути мы имеем обыкновенную сишную структуру плюс указатель на ее описание. Класс: class_struct { 0 magic // всегда равен 1 4 class // class_struct*, указатель на структуру класса более высокого уровня, зачем нужен - непонятно 8 ... // значение неизвестно 12 super_count // количество уровней наследования: 0x18 - один (наследует от Object), // 0х1c - два и т.д. до восьми(0х34), потом 0х10. У интерфейсов тоже 0х10. 16 interface // class_struct*, указатель на какой-либо из интерфейсов класса (на какой именно непонятно), часто просто 0 20 interface_list // указатель на массив с элементами типа class_struct*, все интерфейсы класса 24 ... 28 ... 32 ... 36 ... // указатели на структуры восьми высших суперклассов начиная от Object и кончая this (если поместится) 40 ... 44 ... 48 ... 52 ... 56 size // размер инстанции класса в DWORD'ах 60 this_class // instance_struct*, указатель на инстанцию java.lang.Class соответствующую данному классу 64 access_flags // доступ к классу как описано в VM spec ( 0х1 - public, 0х10 - final и т.д.) 68 ... ... } Здесть я привел только те куски, которые мы будем использовать в дальнейшем и в которых я более или менее уверен. На самом деле class_struct значительно длиннее и содержит кроме того указатели на функции класса, статические переменные и все остальное, что может понадобится виртуальной машине. Все эти структуры по понятным причинам нигде не документированы и разбираться надо вручную - хоть и несложно, но достаточно трудоемко. Если у кого-то есть желание помочь, буду только рад. 3. Особенности версии 1.5 С переходом на последнюю (на момент написания) версию 1.5.0_06 внутренние структуры виртуальной машины претерпели некоторые изменения. К счастью небольшие: изменился в основном порядок полей, значения остались в большинстве прежними. Структура класса выглядит теперь следующим образом: class_struct_1_5 { 0 magic // всегда равен 1 4 class // class_struct*, указатель на структуру класса более высокого уровня, зачем нужен - непонятно 8 ... // значение неизвестно 12 size // размер инстанции класса в DWORD'ах 16 super_count // количество уровней наследования: 0x20 - один (наследует от Object), // 0х24 - два и т.д. до восьми(0х38), потом 0х14. У интерфейсов тоже 0х14. 20 interface // class_struct*, указатель на какой-либо из интерфейсов класса (на какой именно непонятно), часто просто 0 24 interface_list // указатель на массив с элементами типа class_struct*, все интерфейсы класса 28 ... 32 ... 36 ... 40 ... // указатели на структуры восьми высших суперклассов начиная от Object и кончая this (если поместится) 44 ... 48 ... 52 ... 56 ... 60 this_class // instance_struct*, указатель на инстанцию java.lang.Class соответствующую данному классу 64 ... 68 ... // точные значения неизвестны 72 ... 76 ... 80 access_flags // доступ к классу как описано в VM spec ( 0х1 - public, 0х10 - final и т.д.) 84 ... ... } Обратите внимание на переехавшее вперед поле size и сдвинутые по сравнению с версией 1.4 значения поля super_count. При написании кода придется учитывать подобные мелкие отличия. Поэтому будем в самом начале опрашивать версию виртуальной машины и сохранять результат в переменной vm1_5. Интересно кстати, что версии 1.5.0_0x, x<6 используют все еще старые структуры. То есть достаточно глобальные изменения в виртуальной машине не обязательно приурочены к значительному скачку версии - сам по себе примечательный факт. 4. Применение на практике Перейдем к практической части и попробуем приспособить теорию к делу. Для начала решим одну проблему, которая существует почти столько же сколько и сама Ява. А именно напишем функцию sizeof() для объектов. Желающие могут использовать свой любимый поисковик и посмотреть(например по Java+sizeof), сколько и каких решений предлагалось за последние годы, от использования Reflection до вычисления размера занятой памяти и деления его на количество объектов. Точного ответа при этом не давало, что интересно, ни одно. Нам же достаточно просто прочитать поле class_struct.size public static long sizeOf(Object object){ return unsafe.getAddress(unsafe.getAddress(ObjectToAddress(object)+4)+(vm1_5?12:56)); } Функция возвращает результат в DWORD'ах, если нужен в байтах не забудьте умножить на 4. С помощью sizeOf() можно теперь копировать содержимое инстанций - так называемая "shallow copy". "Shallow" - так как в случае внутренних переменных типа Object (и от него производных) копируются естественно только указатели, а не объекты целиком. public static void copyObjectShallow(Object objectSource, Object objectDest) { unsafe.copyMemory(ObjectToAddress(objectSource),ObjectToAddress(objectDest),sizeOf(objectSource)*4); } copyObjectShallow бывает особенно полезна если иметь дело с объектами, содержащими большое количество переменных примитивных типов. То есть когда класс используется в основном для хранения данных, как структура в С. Копировать переменные по одной (единственный штатный способ Явы) - удовольствия мало. Как известно, приведение типов в Яве осуществляется динамически, с учетом иерархии классов. Бинарного каста (reinterpret_cast в терминах С++) Ява к сожалению не поддерживает. Заполним этот пробел. public static Object reinterpret_cast(Object o, Class cl){ unsafe.putAddress(ObjectToAddress(o)+4,unsafe.getAddress(ObjectToAddress(cl)+8)); return o; } reinterpret_cast возвращает указатель на объект о, приведенный к заданному через параметер cl типу. Имеет ли такое преобразование смысл, должен как всегда решать сам пользователь. Не следует только забывать, что ошибка при подобных манипуляциях с памятью почти всегда вызовет не безобидную Java Exception, а что-нибудь вроде Access Violation в виртуальной машине. Классический случай применения reinterpret_cast - когда один и тот же класс загружается два раза двумя разными ClassLoader'ами. Если собираетесь писать многопоточную программу, не забывайте о синхронизации. Например имеет смысл добавить в определения приведенных выше функций слово synchronized. Иначе может случиться так, что разные потоки попытаются одновременно изменять структуры классов и радости тогда будет много. Исходный код класса UnsafeUtil вместе с примерами использования отдельных его функций находится в приложении к статье. 5. Бесконечный final Чтобы лучше оценить те практически неограниченные возможности, которые открывает перед нами манипулирование структурами классов, разберем пример посложнее. Как известно, "final" в объявлении класса запрещает наследование от него. Например классы типов, такие как String, Integer и т.д. умышленно сделаны разработчиками языка конечными. Новички с завидным постоянством спрашивают на форумах, можно ли написать собственный класс строк, наследующий от String, и с таким же постоянством получают ответ "нельзя". И тем не менее правильный ответ - можно. Для простоты и наглядности возьмем функцию hashCode(). Как известно хэш строк вычисляется по алгоритму s[[ *31^(n-1)]] + s[[ *31^(n-2)]] + ... + s[n-1] где n - длина строки и s[i] - i-й символ. Предположим теперь, что нас не устраивает стандартный алгоритм и мы хотим вычислять сумму не с начала строки, а с конца. Вот так: s[n-1]*31^(n-1) + s[n-2]*31^(n-2) + ... + s[0] То есть нужен класс, который наследует от String и имплементирует новую hashCode(). И именно эти свойства имеет класс MagicString, который можно найти в директории /string в исходниках к статье. MagicStringWthStub реализует ту же самую идею, только чуть элегантнее, например без использования Reflection. Недостатком в этом случае является необходимость написания stub'а, что впрочем можно легко автоматизировать. MagicString обходится без дополнительных классов. Код самих классов я здесь приводить не хочу, чтобы не загромождать статью. Основная идея состоит в том, что мы вносим String в список суперклассов(смещения 24-52 + поле super_count) и подправляем поле access_flags нужным образом (убираем final). Детали реализации можно посмотреть в приложенных исходниках. Проверим теперь MagicString в действии: String s = (String)(Object)(new MagicStringWithStub("AB")); System.out.println("Magic String hashcode: "+s.hashCode()); String s1 = new String("AB"); System.out.println("Standard String hashcode: "+s1.hashCode()); На выходе получим Magic String hashcode: 2111 Standard String hashcode: 2081 Как видим, единственное небольшое неудобство состоит в том, что кастить в String приходится через Object. Понятно почему: компилятор-то о наших играх ничего не знает. В остальном мы полностью достигли цели: получили String с нестандартным хэш-кодом. В следующей статье (при условии, что у меня дойдут руки ее написать :)) мы научимся создавать на Яве самомодифицирующийся код. Благодарности Quantum - за вдумчивое и терпеливое рецензирование черновых вариантов статьи. Если я не последовал каким-либо его советам, то исключительно по причине собственной лени. Приложение [[http://wasm.ru/pub/27/files/unsafe_java_1_code.zipunsafe_java_1_code.zip&#093;] (7 KB) - Примеры к статье

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
 
  • 1, Георгий, 20:59, 09/03/2008 [ответить] [смотреть все]
  • +/
    Очень хорошая статья. автор-молодец
     
  • 2, max, 12:59, 21/02/2009 [ответить] [смотреть все]
  • +/
    отличная статья
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor