Câu trả lời:
Vì Chuỗi Java dựa trên mảng ký tự và Java tự động kiểm tra giới hạn mảng, nên lỗi tràn bộ đệm chỉ có thể xảy ra trong các trường hợp bất thường:
Các ngôn ngữ được quản lý như Java và C # không gặp những vấn đề này, nhưng các máy ảo cụ thể (JVM / CLR / etc) thực sự chạy mã thì có thể.
Đối với tất cả các ý định và mục đích, không.
Java có kiểm tra giới hạn mảng sẽ kiểm tra xem dữ liệu không thể được truy cập từ khu vực bên ngoài mảng được cấp phát. Khi một người cố gắng truy cập khu vực vượt quá kích thước của mảng, một ArrayOutOfBoundsngoại lệ sẽ được ném ra.
Nếu có lỗi tràn bộ đệm, có thể là do lỗi trong Máy ảo Java và theo hiểu biết của tôi, không phải do hành vi dự kiến được viết trong Đặc tả ngôn ngữ Java cũng như Đặc tả máy ảo Java.
Có và không. Không, ở chỗ, bạn không thể thực sự tạo ra lỗi mở cho mình lỗ hổng tràn bộ đệm vì nó là một mô hình bộ nhớ được quản lý. Tuy nhiên, có thể có lỗ hổng tràn bộ đệm trong JVM và JDK. Xem phần tư vấn này của Secunia:
http://secunia.com/advisories/25295
Hoặc xem các lời khuyên cũ này về một số lỗ hổng JDK và JRE trước đây:
Lỗ hổng tràn số nguyên và bộ đệm trong môi trường thời gian chạy Java (JRE) "unpack200" JAR Unpacking Utility Có thể dẫn đến leo thang các đặc quyền https://download.oracle.com/sunalerts/1020225.1.html
Các lỗ hổng tràn bộ đệm và số nguyên trong Môi trường thời gian chạy Java (JRE) với việc giải nén các applet và ứng dụng Java Web Start bằng cách sử dụng tiện ích giải nén JAR "unpack200" có thể cho phép một applet hoặc ứng dụng không đáng tin cậy nâng cao đặc quyền. Ví dụ: một applet không đáng tin cậy có thể tự cấp cho mình quyền đọc và ghi các tệp cục bộ hoặc thực thi các ứng dụng cục bộ mà người dùng đang chạy applet không tin cậy có thể truy cập được.
Sun thành thật cảm ơn, "regenrecht" đã làm việc với iDefense VCP ( http://labs.idefense.com/vcp/ ) và Chris Evans của Google vì đã đưa những vấn đề này cho chúng tôi.
Nhiều lỗ hổng đã được xác định trong Sun Java Development Kit (JDK) và Java Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23
Một lỗ hổng không xác định liên quan đến việc "sử dụng sai các lớp hệ thống" đã được nhóm bảo mật Fujitsu báo cáo. Ngoài ra, Chris Evans từ Nhóm bảo mật của Google đã báo cáo lỗi tràn số nguyên dẫn đến tràn bộ đệm trong trình phân tích cú pháp ICC được sử dụng với tệp JPG hoặc BMP và lệnh mở () không chính xác tới / dev / tty khi xử lý một số tệp BMP nhất định.
Tràn bộ đệm theo nghĩa nghiêm ngặt của việc ghi đè lên ngăn xếp hoặc chính đống sẽ yêu cầu:
Tràn bộ đệm theo nghĩa là bạn có mã sử dụng bộ đệm và mã của bạn chịu trách nhiệm phân tích cú pháp nó một cách chính xác nhưng không thể làm như vậy. Ví dụ: Bạn có thể viết một trình phân tích cú pháp XML và ai đó có thể cung cấp cho bạn một yêu cầu không đúng định dạng (hoặc hợp pháp nhưng không phổ biến), do thiết kế của trình phân tích cú pháp của bạn ghi đè dữ liệu đã được xác thực trước đó bằng một số tải trọng khiến ứng dụng của bạn hoạt động không tốt.
Dạng thứ hai này ít xảy ra hơn nhưng một hàm làm sạch chuỗi sql được viết kém được phân phối rộng rãi có vấn đề như đây sẽ là một mục tiêu hấp dẫn.
Máy ảo Java (và .Net) bắt mã cố gắng ghi bên ngoài bộ nhớ dành riêng. Các ứng dụng không xử lý điều này một cách chính xác vẫn có thể gây ra sự cố bảo mật. Nếu người dùng độc hại có thể kích hoạt các ngoại lệ bằng cách nhập thông tin đầu vào không hợp lệ, họ có thể thực hiện các cuộc tấn công từ chối dịch vụ chẳng hạn.
Như đã được chỉ ra, Java, với tư cách là một ngôn ngữ, có giới hạn kiểm tra tất cả các truy cập bộ nhớ và nếu có lỗi ở đây thì JVM là lỗi chứ không phải chương trình. Tuy nhiên, điều cần lưu ý, đó là một đối số tương tự như rò rỉ bộ nhớ trong Java; trong khi không thể phá vỡ ngăn xếp, ArrayOutOfBoundsException ở sai vị trí, không được xử lý đúng cách, vẫn có thể làm hỏng hệ thống của bạn.
Bạn có thể hình dung ra lỗi tràn bộ đệm trong một chương trình Java nếu bạn đang sử dụng cơ sở Java Native Interace (JNI) để gọi mã bên ngoài và mã bên ngoài có vấn đề có thể khai thác được. Điều này khá phổ biến, vì hầu hết các ứng dụng đều tránh sử dụng JNI nếu có thể.
Phương thức có thể ghi vào các mục nhập hợp lệ của một mảng mà nó không có ý định, thường là thông qua tràn số nguyên.
Ví dụ, những điều sau không đủ để kiểm tra giới hạn:
/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */IIRC, StringBufferđã từng có một lỗi như vậy, nhưng không có gì thú vị mà bạn có thể làm với nó.
0 <= off && 0 <= len && off <= buff.length-lenTôi nghĩ vậy. Đừng trích dẫn tôi. Nó trông giống nhau nhưng không có khả năng bị tràn (trong off + len ban đầu có thể là số âm và do đó rõ ràng là nhỏ hơn chiều dài mảng). Đảm bảo rằng không có lập trình viên bảo trì nào từng "dọn dẹp" nó thành dạng hiển nhiên. Tôi thấy tràn số nguyên rất khó hiểu. Phải suy nghĩ về nó một lúc, và sau đó có một sự nghi ngờ dai dẳng rằng tôi đã nhầm. Nhưng tất nhiên, cần phải có một người đánh giá khác và lập trình viên ban đầu - tất nhiên là không thể có lỗi nào có thể vượt qua được! (not)
Một trong những tính năng chính của JAVA là Bảo mật. Các chương trình được viết bằng ngôn ngữ thông dịch không dễ bị khai thác tràn bộ đệm, nhưng bạn luôn có thể gây ra tràn bộ đệm trong chính Trình thông dịch. Mặc dù nó sẽ khó khăn. Tương tự như vậy, Python cũng là một ngôn ngữ thông dịch và an toàn không bị tràn bộ đệm.