我将重点谈谈这个案子。SADebugServerAttachingConnector
以下是您链接到的文档的Java 11版本中的更多引用:
SA 调试服务器连接连接器
调试器应用程序可以使用此连接器在运行调试器的计算机以外的计算机上调试进程或核心文件。
此连接器使用 RMI 与远程计算机上运行的“调试服务器”进行通信。在调用此连接器上的 attach() 方法之前,必须在远程计算机上启动调试服务器,并告知要调试的进程或核心文件。
要调试的进程不需要在调试模式下启动(即,使用 -agentlib:jdwp 或 -Xrunjdwp)。
1)为什么像Xrunjdwp这样的调试选项首先存在呢?
SA Debug Server 方法允许您调试一个 Java 进程,在该进程中,您不想使用代理启动(例如,出于安全原因),或者您没有远见卓识来执行此操作。
相反,代理方法适用于您不希望设置 SA 调试服务器来调试 Java 应用程序的麻烦的情况。
这是“课程的马”...正如他们所说。
2)SADebugServerAttachingConnector如何在不获取参数中端口号的情况下工作?
调试器正在使用 RMI 默认端口与 SA 调试服务器通信。SA 调试服务器使用服务器和目标已知的机制连接到目标 JVM。它可能是引擎盖下特定于操作系统的机制。例如,在Linux上,它可以使用API。不需要涉及网络套接字和端口。ptrace(2)
3)文档没有说明任何关于需要root权限的内容。允许非特权用户对未在调试模式下启动的 jvm 实例进行任意调试,这难道不是一个严重的权限提升漏洞吗?
文档指出,需要专门设置 SA 调试服务器与目标 VM 之间的链接。这是在启动 SA 调试服务器时完成的。
操作系统级访问控制不允许非根 SA 调试服务器使用(例如)系统调用访问属于其他用户/用户 ID 的 Java 进程。操作系统不会让您启动根 SA 调试服务器,除非您已经具有根权限。因此,无论是在根还是非根情况下,都不会升级特权。ptrace
(将任何未公开或未修补的操作系统级根升级错误进行模块化...当然。