[doc] Please clarify whether a binary with DEBUG_TRACE 1 is equally secure

[attila-lendvai]

IOW, should packagers feel free to compile/package a dropbear binary that has the -v option available at runtime?

[mkj]

Just compiling the binary doesn't immediately have any security concerns, the o will not be executed if -v isn't passed.

Running with -v does have some security implications.

• Some untrusted arguments aren't escaped, so terminal escape characters could cause UI confusion or other terminal tricks. eg
  

  dropbear/src/svr-auth.c

  Line 266 in 0f9f95d

  TRACE(("leave checkusername: user '%s' doesn't exist", username))

  
  That line is also interesting in that it would log a bad username, which could be a mistyped password from some clients.

• Additional logging may be less careful about timing to avoid leaking the existence of usernames.

• Some TRACE() %s arguments may be NULL. glibc and musl both will just print (null) though that isn't standard. eg remoteport here

  dropbear/src/netio.c

  Line 334 in 0f9f95d

  TRACE(("handling %s port %s socket %d", c->remotehost, c->remoteport, c->sock));

• Prior to 2674736 there was a TRACE() in the sigchld handler. I think that will probably be safe, calling down into fprintf(stderr) and writing to a FD without allocation, but that isn't guaranteed by libc.

All of those could be solved, but would need some auditing work.