Java имеет переполнение буфера?

Предполагая, что прямоугольник должен быть параллелен оси x и y, поскольку это похоже на ситуацию из предыдущих комментариев и ответов.

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

Рассмотрим случай

a: (1,1), (4,4)
b: (2,2), (5,3)

. В этом случае мы видим, что для пересечения высота должна быть bTop - bBottom, поскольку вертикальная часть b полностью содержится в a.

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

if aRight <= bLeft or bRight <= aLeft or aTop <= bBottom or bTop <= aBottom:
    # There is no intersection in these cases
    return 0
else:
    # There is some intersection

    if aRight >= bRight and aLeft <= bLeft:
        # From x axis point of view, b is wholly contained in a
        width = bRight - bLeft
    elif bRight >= aRight and bLeft <= aLeft:
        # From x axis point of view, a is wholly contained in b
        width = aRight - aLeft
    elif aRight >= bRight:
        width = bRight - aLeft
    else:
        width = aRight - bLeft

    if aTop >= bTop and aBottom <= bBottom:
        # From y axis point of view, b is wholly contained in a
        height = bTop - bBottom
    elif bTop >= aTop and bBottom <= aBottom:
        # From y axis point of view, a is wholly contained in b
        height = aTop - aBottom
    elif aTop >= bTop:
        height = bTop - aBottom
    else:
        height = aTop - bBottom

return width * height
90
задан Tom Hawtin - tackline 26 January 2009 в 13:37
поделиться

9 ответов

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

  1. при вызове собственного кода через JNI
  2. В самой JVM (обычно писавшимся в C++)
  3. , интерпретатор или JIT-компилятор не работают правильно (байт-код Java передал под мандат граничные проверки)
102
ответ дан Michael Borgwardt 5 November 2019 в 14:19
поделиться

Во всех отношениях, нет.

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

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

13
ответ дан coobird 5 November 2019 в 14:19
поделиться

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

24
ответ дан Brian Rasmussen 5 November 2019 в 14:19
поделиться

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

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

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

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

9
ответ дан ShuggyCoUk 5 November 2019 в 14:19
поделиться

Да и нет. Нет, в этом Вы не можете действительно создать по ошибке открытый сами до уязвимости переполнения буфера, потому что это - модель управляемой памяти. Однако могут быть уязвимости переполнения буфера в 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 Запускаются, приложения с помощью утилиты распаковки "unpack200" JAR могут позволить недоверяемому апплету или приложению наращивать полномочия. Например, недоверяемый апплет может дать себе разрешения, чтобы считать и записать локальные файлы или выполнить локальные приложения, которые доступны для пользователя, выполняющего недоверяемый апплет.

    Sun подтверждает с благодарностью, "regenrecht" работающий с iDefense VCP ( http://labs.idefense.com/vcp/ ) и Chris Evans Google для того, чтобы обратить наше внимание на эти проблемы.

  • Несколько уязвимостей были определены в Комплекте разработчика для Java (JDK) Sun и среде выполнения Java (JRE). https://security.gentoo.org/glsa/200705-23

    неуказанная уязвимость, включающая "неправильное использование системных классов", сообщался службой безопасности Fujitsu. Кроме того, Chris Evans от Google Security Team сообщил о целочисленном переполнении, приводящем к переполнению буфера в синтаксическом анализаторе ICC, используемом с JPG или файлами BMP, и неправильное открытое () звонит в/dev/tty при обработке определенных файлов BMP.

9
ответ дан Richard Chambers 5 November 2019 в 14:19
поделиться

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

4
ответ дан Mendelt 5 November 2019 в 14:19
поделиться

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

3
ответ дан falstro 5 November 2019 в 14:19
поделиться

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

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

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

IIRC, StringBuffer когда-то имел ошибку как этот, но не было ничего интересного, которое Вы могли сделать с ним.

3
ответ дан Tom Hawtin - tackline 5 November 2019 в 14:19
поделиться

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

2
ответ дан Tim Howland 5 November 2019 в 14:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: