[Bug] Admin IPC accepts malformed request bytes that admin HTTP rejects

Đang mở
  • Có gì không ổn?
#7,044 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Read IpcRequestHandler.readRequest, IpcService.handleClient, and IpcRequestHandler.handleCommand, then compare their input handling with AdminRpcServlet and AdminJsonRpcRequestHandler.handleRequest. Reproduce the malformed-byte request using the commands in the issue. Done means IPC and admin HTTP reject the same invalid UTF-8 or surrounding control characters with -32700, without calling the method.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Bug Description

Admin IPC changes a request's bytes before it parses them. Invalid UTF-8 inside the request is replaced with U+FFFD, and control characters before or after the JSON object are removed, so admin_example runs with input the client didn't send. Admin HTTP passes the same bytes to the parser unchanged and returns -32700.

Environment

Network
Mainnet configuration, local node started with --p2p-disable true

Software Versions

OS: Fedora 44, Linux 7.2.9-200.fc44.x86_64
JVM: Temurin 1.8.0_504 amd64
Git Commit: 2d99513742d92af4f7b5f68791d809582a9e4549
Version: 4.8.2.3
Code: 18830

Configuration
FullNode built from release_v4.8.3 with the shipped config.conf plus node.admin.ipc.enable = true and node.admin.http.enable = true.

Expected Behavior

The same request bytes get the same reply over IPC and admin HTTP. A request that isn't valid UTF-8 JSON gets -32700 and the method isn't called.

Actual Behavior

Over IPC, a request with an 0xff byte inside a string runs admin_example and returns a result with U+FFFD where the 0xff byte was. Over admin HTTP the same bytes return -32700. A truncated UTF-8 sequence behaves the same way. A NUL after the object or a vertical tab before it also succeeds over IPC and returns -32700 over HTTP. The node logs nothing for any of these IPC requests.

Frequency

  • Always (100%)
  • Frequently (>50%)
  • Sometimes (10-50%)
  • Rarely (<10%)

Steps to Reproduce

  1. Start a FullNode with node.admin.ipc.enable = true and node.admin.http.enable = true.
  2. Send a request with an 0xff byte inside a string over IPC, then the same bytes to admin HTTP.
printf '{"jsonrpc":"2.0","method":"admin_example","params":["a\xffb","b"],"id":7}\n' | socat - UNIX-CONNECT:output-directory/ipc/<pid>.sock
printf '{"jsonrpc":"2.0","method":"admin_example","params":["a\xffb","b"],"id":7}' | curl -s -H 'Content-Type: application/json' --data-binary @- http://127.0.0.1:8575/admin

Logs and Error Messages

IPC   {"jsonrpc":"2.0","id":7,"result":"a�b:b"}
HTTP  {"jsonrpc":"2.0","id":null,"error":{"code":-32700,"message":"JSON parse error"}}

The � in the IPC reply is U+FFFD, sent as the bytes EF BF BD.

Additional Context (Optional)

Possible Solution
IpcRequestHandler.readRequest decodes the line into a String, IpcService.handleClient trims it, and IpcRequestHandler.handleCommand encodes it again before calling AdminJsonRpcRequestHandler.handleRequest. AdminRpcServlet calls the same method with the raw body. Passing the IPC line bytes straight through, without the trim, gives both transports the same input.

Ngôn ngữ chính
Java
Star
4.2k
Fork
1.8k
Merge trung bình
2 ngày 15 giờ
Pull request đã merge (30 ngày)
41

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tronprotocol/java-tron

Tất cả issue của tronprotocol/java-tron

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.