Безопасность программной платформы Java

В бинарном виде программы платформы Java представляют собой не машинный код, а промежуточный байткод. JVM выполняет верификацию этого байткода перед запуском, предотвращая выполнение опасных операций, таких как переходы по неверным адресам, которые могут соответствовать данным, а не инструкциям. Это также позволяет JVM обеспечивать контроль границ массивов и другие ограничения времени исполнения. Благодаря этому программы на Java существенно менее подвержены ошибкам безопасности памяти (например, переполнение буфера), чем программы на языках, не гарантирующих безопасность памяти, например на C.

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

Платформа Java предоставляет менеджер безопасности, позволяющий запускать недоверенный байткод в сандбоксированной среде, защищая от вредоносного или ошибочного программного обеспечения за счёт ограничения доступа к ключевым функциям платформы и её API. Например, недоверенному коду может быть запрещено читать или изменять файлы на локальной файловой системе, выполнять произвольные команды с привилегиями пользователя, обращаться к сетевым ресурсам, получать доступ к приватному состоянию объектов через рефлексию или инициировать завершение работы JVM.

Менеджер безопасности также позволяет криптографически подписывать Java-программы. В таком случае пользователь может разрешить выполнение подписанного кода с полными привилегиями, если он подписан доверенным издателем.

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

Библиотека классов Java содержит ряд прикладных интерфейсов (API), связанных с безопасностью: реализации стандартных криптографических алгоритмов, средства аутентификации и протоколы защищённой передачи данных.

Класс sun.misc.Unsafe — это внутренняя утилита в языке Java, реализующая набор низкоуровневых небезопасных операций^[1]. Он не входит в официальный набор классов Java, однако используется внутренними библиотеками Java. Класс подключается из неофициального модуля jdk.unsupported, а начиная с Java 11 — частично мигрировал в jdk.internal.misc.Unsafe (является частью модуля java.base)^[1].

Главная особенность — возможность прямого управления памятью и адресацией, манипуляций с объектами и полями, управления потоками и реализация низкоуровневых механизмов конкурентности (сравнимых с управлением памятью на C).

Объявление класса: public final class Unsafe;. Это синглтон-класс с приватным конструктором^[2].

Класс включает методы (многие объявлены как native и используют Java Native Interface), включая:

• получение экземпляра Unsafe через sun.reflect.Reflection.
• получение значения по смещению в объекте. Аналогичные методы — getBoolean(), getByte(), getShort(), getChar(), getLong(), getFloat(), getDouble().
• запись значения по смещению в объекте. Аналогичные методы: putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), putDouble().
• доступ к ссылочным полям.
• методы чтения и записи значений по произвольному адресу или в выделенной памяти.
• выделение блока нативной памяти (аналог malloc()).
• изменение размера блока памяти (аналог realloc()).
• инициализация памяти байтовым значением (аналог memset()).
• копирование блоков памяти (аналог memcpy()).
• освобождение памяти (аналог free()).
• методы для работы со статическими и объектными полями, массивами, адресным пространством, инициирования классов, работы с блокировками, исключениями, атомарными операциями, межпоточной синхронизацией и др.

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

Пример использования:

package org.wikipedia.example;

import java.lang.reflect.Field;

import sun.misc.Unsafe;

public class Example {
    public static void main(String[] args) throws Exception {
        // Получение экземпляра Unsafe через рефлексию
        Field f = Unsafe.class.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        Unsafe unsafe = (Unsafe)f.get(null);

        // Выделение блока памяти на 8 байт
        long memoryAddress = unsafe.allocateMemory(8L);

        try {
            // Запись и чтение значения long
            unsafe.putLong(memoryAddress, 123456789L);
            long value = unsafe.getLong(memoryAddress);
            System.out.printf("Value from memory: %d%n", value); // Output: 123456789
        } finally {
            // Освобождение выделенной памяти
            unsafe.freeMemory(memoryAddress);
        }
    }
}

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

package org.wikipedia.example;

import java.lang.reflect.Field;

import sun.misc.Unsafe;

public class NativeMemory implements AutoCloseable {
    private static final Unsafe unsafe;
    private final long address;
    private final long size;

    static {
        try {
            Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
            theUnsafe.setAccessible(true);
            unsafe = (Unsafe)theUnsafe.get(null);
        } catch (Exception e) {
            throw new RuntimeException("Unable to access Unsafe", e);
        }
    }

    public NativeMemory(long size) {
        this.size = size;
        this.address = unsafe.allocateMemory(size);
    }

    public void putByte(long offset, byte value) {
        checkBounds(offset, 1);
        unsafe.putByte(address + offset, value);
    }

    public byte getByte(long offset) {
        checkBounds(offset, 1);
        return unsafe.getByte(address + offset);
    }

    private void checkBounds(long offset, long bytes) {
        if (offset < 0 || offset + bytes > size) {
            throw new IndexOutOfBoundsException(String.format("Offset out of bounds: %d", offset));
        }
    }

    @Override
    public void close() {
        unsafe.freeMemory(address);
    }
}

Использование:

package org.wikipedia.example;

public class Main {
    public static void main(String[] args) {
        try (NativeMemory mem = new NativeMemory(1024)) {
            mem.putByte(0, (byte)42);
            System.out.printf("Value: %s%n", mem.getByte(0));
        }
    }
}

В 2012 году троянец Flashback эксплуатировал уязвимость в Java, которая не была оперативно закрыта компанией Apple, несмотря на то, что Oracle выпустила патч^[7]. Позже Apple выпустила инструмент для удаления вредоносной программы для пользователей Mac OS X Lion, не использующих Java^[8]. Начиная с Java 7, обновление 4, Oracle стала самостоятельно выпускать дистрибутивы Java для Lion и более новых версий macOS^[9].

В октябре Apple выпустила обновление, полностью удалившее плагин Java из всех браузеров^[10]. Это было воспринято как сознательное дистанцирование Apple от Java^[11].

В январе была обнаружена уязвимость нулевого дня во всех версиях Java 7, использовавшаяся в сети с момента появления^[12]. Причиной стала попытка исправить более раннюю брешь^[13]. В ответ Apple добавила последний Java-плагин в "черный список"^[14]. Oracle выпустила патч (обновление 11) через три дня^[15]. Microsoft также выпустила заплатку для Internet Explorer 6—8^[16].

Кибершпионское ПО Red October эксплуатировало уязвимость, исправленную ещё в октябре 2011 года^[17]. Сайт Reporters Without Borders был скомпрометирован уязвимостью в Java до релиза Update 11^[18].

Вскоре после выхода Update 11 была выявлена новая уязвимость^[19], позднее подтверждённая^[20]. Было также установлено, что защитный режим Java тоже подвержен реализации из-за ошибки^[21]. Вслед за этим Mozilla по умолчанию отключила Java (а также Adobe Reader и Microsoft Silverlight) в Firefox^[22], а Apple снова заблокировала самый свежий Java-плагин^[23].

В феврале Twitter сообщил о предотвращённой атаке и порекомендовал пользователям отключить Java^[24]. Позже в том же месяце о взломе через Java отчиталась Facebook^[25], а также Apple^[26]. Было обнаружено, что причиной стал взлом форума для разработчиков iPhone, использованного для атаки на Twitter, Facebook и Apple^[27]. Сам форум не знал о наличии угрозы^[28]. В дальнейшем аналогичные инциденты произошли с Microsoft^[29].

Позже была обнаружена уязвимость, позволявшая полностью обходить песочницу Java в первоначальном релизе Java 7, а также в обновлениях 11 и 15^[30]. В марте троянец McRat эксплуатировал ещё одну уязвимость нулевого дня в Java^[31]. Oracle в скором времени выпустила очередной патч для устранения уязвимости^[32].