On 2023-10-16 06:08, Alejandro Colomar wrote:
Hi Siddhesh,
On Mon, Oct 16, 2023 at 02:19:23AM -0400, Siddhesh Poyarekar wrote:
The binutils security policy[1] states that diagnostic tools should not
be expected to be safe without sandboxing, so it doesn't make sense to
recommend it as the alternative to ldd, especially since it is not a
drop-in replacement. Recommend sandboxing instead, since that is in
fact the safest known way at the moment to deal with untrusted binaries.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/SECURITY.txt
Signed-off-by: Siddhesh Poyarekar <siddhesh@xxxxxxxxxx>
---
man1/ldd.1 | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/man1/ldd.1 b/man1/ldd.1
index cca96ec4d..f86798566 100644
--- a/man1/ldd.1
+++ b/man1/ldd.1
@@ -94,20 +94,8 @@ Thus, you should
.I never
employ
.B ldd
-on an untrusted executable,
+on an untrusted executable without appropriate sandboxing,
since this may result in the execution of arbitrary code.
-A safer alternative when dealing with untrusted executables is:
-.PP
-.in +4n
-.EX
-$ \fBobjdump \-p /path/to/program | grep NEEDED\fP
Should we maybe keep this example, and suggest using it with sandboxing?
Or is it not useful anymore?
I don't see the point TBH. I wouldn't mind if that example was replaced
with lddtree as the alternative since it is functionally equivalent.
However it would be a safer recommendation to put that too inside a
sandbox because IMO you'd generally never want to run or even analyze
arbitrary executables without proper sandboxing.
Thanks,
Sid
