Есть ли в Java переполнение буфера?

Есть ли в Java переполнение буфера? Если да, можете ли вы дать мне сценарии?

Поскольку строки Java основаны на массивах символов, а Java автоматически проверяет границы массива, переполнение буфера возможно только в необычных сценариях:

1. Если вы вызываете собственный код через JNI
2. В самой JVM (обычно написанной на C ++)
3. Интерпретатор или JIT-компилятор работает некорректно (проверка границ обязательного байт-кода Java)

Управляемые языки, такие как Java и C #, не имеют этих проблем, но определенные виртуальные машины (JVM / CLR / и т. Д.), На которых фактически выполняется код, могут.

Во всех смыслах и целях нет.

В Java есть проверка границ массива, которая проверяет, что к данным нельзя получить доступ из области за пределами выделенного массива. Когда кто-то пытается получить доступ к области, превышающей размер массива,ArrayOutOfBounds будет выброшено исключение.

Если происходит переполнение буфера, это, вероятно, связано с ошибкой в ​​виртуальной машине Java и, насколько мне известно, не является предполагаемым поведением, описанным в Спецификациях языка Java или Спецификациях виртуальной машины Java.

Да и нет. Нет, в том смысле, что вы действительно не можете создать ошибочно открытую уязвимость для переполнения буфера, потому что это модель управляемой памяти. Однако в JVM и JDK могут быть уязвимости переполнения буфера. См. Этот совет Secunia:

http://secunia.com/advisories/25295

Или посмотрите эти старые рекомендации по нескольким предыдущим уязвимостям JDK и JRE:

• Уязвимости, связанные с целыми числами и переполнением буфера в среде выполнения Java (JRE) "unpack200" Утилита распаковки JAR-файлов может привести к повышению привилегий https://download.oracle.com/sunalerts/1020225.1.html

  Целочисленные уязвимости и уязвимости переполнения буфера в среде выполнения Java (JRE) с распаковкой апплетов и приложениями Java Web Start, использующими утилиту распаковки JAR "unpack200", могут позволить ненадежному апплету или приложению повысить привилегии. Например, ненадежный апплет может предоставить себе разрешения на чтение и запись локальных файлов или выполнение локальных приложений, доступных пользователю, запускающему ненадежный апплет.

  Sun благодарит "regenrecht" за работу с iDefense VCP ( http://labs.idefense.com/vcp/ ) и Криса Эванса из Google за то, что они обратили наше внимание на эти проблемы.

• В Sun Java Development Kit (JDK) и Java Runtime Environment (JRE) обнаружено множество уязвимостей. https://security.gentoo.org/glsa/200705-23

  Группа безопасности Fujitsu сообщила о неуказанной уязвимости, связанной с «неправильным использованием системных классов». Кроме того, Крис Эванс из группы безопасности Google сообщил о целочисленном переполнении, которое привело к переполнению буфера в анализаторе ICC, используемом с файлами JPG или BMP, и неправильном вызове open () для / dev / tty при обработке определенных файлов BMP.

Переполнение буфера в строгом смысле перезаписи стека или самой кучи потребует либо:

1. Ошибка в фреймворке (они существовали в прошлом и могут снова появиться)
2. Использование JNI (по сути, больше не используется управляемый код)

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

Эта последняя форма менее вероятна, но плохо написанная широко распространенная функция очистки строк sql, у которой была такая проблема, как это, была бы привлекательной целью.

Виртуальные машины Java (и .Net) отлавливают код, который пытается писать вне зарезервированной памяти. Приложения, которые не справляются с этим правильно, по-прежнему могут вызывать проблемы с безопасностью. Если злоумышленники могут запускать исключения, вводя недопустимые данные, они могут, например, выполнить атаки отказа в обслуживании.

Как уже отмечалось, Java как язык имеет проверку границ при любом доступе к памяти, и если здесь есть ошибка, то виновата JVM, а не программа. Однако следует отметить, что это аналогичный аргумент утечкам памяти в Java; хотя невозможно разбить стек, исключение ArrayOutOfBoundsException в неправильном месте, которое не обрабатывается правильно, все же может в конечном итоге испортить вашу систему.

Вероятно, вы могли вызвать переполнение буфера в программе Java, если бы вы использовали средство Java Native Interace (JNI) для вызова внешнего кода, а внешний код имел уязвимую проблему. Это довольно необычно, поскольку большинство приложений по возможности избегают использования JNI.

Метод может выполнять запись в действительные записи массива, которые он не намеревался делать, обычно через целочисленное переполнение.

Например, для проверки границ недостаточно:

/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */

У IIRC StringBufferкогда-то была такая ошибка, но с ней ничего интересного не было.

Одна из ключевых особенностей JAVA - безопасность. Программы, написанные на интерпретируемых языках, не подвержены эксплойту переполнения буфера, но вы всегда можете вызвать переполнение буфера в самом Интерпретаторе. Хотя будет сложно. Точно так же Python также является интерпретируемым языком и защищен от переполнения буфера.