Re: runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ?

[Mark Wielaard]

Hi Milian,

On Mon, 2022-07-11 at 18:40 +0200, Milian Wolff wrote:
> in heaptrack I have code to runtime attach to a program and then
> rewrite the 
> various rel / rela / jmprel tables to intercept calls to malloc & friends.
> 
> This works, but now I have received a crash report for what seems to
> be an 
> invalid DSO file: The jmprel table contains an invalid entry which
> points to 
> an out-of-bounds symbol, leading to a crash when we try to look at
> the 
> symbol's name.
> 
> I would like to protect against this crash by detecting the invalid
> symbols. 
> But to do that, I would need to know the size of the symbol table,
> which is 
> much harder than I would have hoped:
> 
> We have:
> 
> ```
> #define DT_SYMTAB 6   /* Address of symbol table */
> #define DT_SYMENT 11  /* Size of one symbol table
> entry */
> ```
> 
> But there is no `DT_SYMSZ` or similar, which we would need to
> validate symbol 
> indices. Am I overlooking something or is that really missing? Does
> anyone 
> know why? The other tables have that, e.g.:
> 
> ```
> #define DT_PLTRELSZ   2   /* Size in bytes of PLT relocs */
> #define DT_RELASZ 8   /* Total size of Rela relocs */
> #define DT_STRSZ  10  /* Size of string table */
> #define DT_RELSZ  18  /* Total size of Rel relocs
> */
> ```
> 
> Why is this missing for the symtab?
>
> The only viable alternative seems to be to mmap the file completely
> to access 
> the Elf header and then iterate over the Elf sections to query the
> size of the 
> SHT_DYNSYM section. This is pretty complicated, and costly. Does
> anyone have a 
> better solution that would allow me to validate symbol indices?

I don't know why it is missing, but it is indeed a tricky issue. You
really want to know the number of elements (or the size) of the symbol
table, but it takes a little gymnastics to get that. Di Chen recently
(or actually not that recently, I just still haven't reviewed, sorry!)
posted a patch for 
https://sourceware.org/bugzilla/show_bug.cgi?id=28873 to print out the
symbols from the dynamic segment 
https://sourceware.org/pipermail/elfutils-devel/2022q2/005086.html

> PS: eu-elflint reports this for the broken DSOs e.g.:
> ```
> $ eu-elflint libQt5Qml.so.5.12
> section [ 3] '.dynsym': symbol 1272: st_value out of bounds
> section [ 3] '.dynsym': symbol 3684: st_value out of bounds
> section [29] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not
> match 
> .got section size 18340
> section [29] '.symtab': _DYNAMIC symbol size 0 does not match dynamic
> segment 
> size 336
> section [29] '.symtab': symbol 25720: st_value out of bounds
> section [29] '.symtab': symbol 27227: st_value out of bounds
> ```
> 
> Does anyone know how this can happen? Is this a bug in the toolchain?

Try with eu-elflint --gnu which suppresses some known issues.
Also could you show those symbol values (1272, 3684, 25720, 27227) they
might have a special type, so their st_value isn't really an address?

Cheers,

Mark

debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

Hello elfutils-devel@

I'm working on a use case for debuginfod (in LLVM) that needs a solution
for authentication and authorization of users when accessing source and
debug information. I've put together a short RFC for how this might work,
based on how git and Docker CLIs handle credentials. It should be fairly
straightforward to implement and to generalize to new credential types.

Please take a look; it'd be good to have a consensus on how this should
work across interested debuginfod implementations before moving forward
towards implementation.

-- 
debuginfod Credential Helper RFCBackground

debuginfod is a simple HTTP-based protocol allowing clients to obtain debug
information from servers. The de-facto standard includes environment
variables for pointing clients at available debuginfod servers, but it
includes no mechanism to provide credentials.

This approach works well for fully open-source projects, but debuginfod is
also particuarly useful for the highly-stripped binaries and constrained
environments found in the embedded space. There, it’s common for licensing
constraints to require access to source and debug information to be
restricted to specific users.
Proposal

debuginfod clients could support a new DEBUGINFOD_CREDENTIAL_HELPER environment
variable. This would provide a command that a debuginfod client could run
to obtain credentials to supply to the server, much like Git or Docker
credential helpers do.

No modifications are proposed to generic debuginfod server implementations,
since specific authentication and authorization decisions are usually quite
domain-specific, and it’s fairly easy to write or configure a custom
debuginfod server to make them.

The proposal also omits any mechanism for the client to interactively
prompt the user for their credentials or to retrieve them from storage;
this is left to the credential helper.
Protocol

The behavior of the credential helpers broadly follows the example set by
Git and Docker.

The DEBUGINFOD_CREDENTIAL_HELPER environment variable contains a string
indicating the command to run. If the string begins with an absolute path,
the command is the verbatim string. Otherwise, the command is the string
prepended with debuginfod-credential-.

Once interpreted, the given command is executed in the shell with one
additional argument to indicate the operation type. This is always get.

The helper reads a description of the requested credential from stdin and
writes a description of the found credential to stdout. Errors may be
reported to stderr.
Credential Format

Credential requests and found credentials are both broadly described using
Git credential helpers’ input/output format
, with some modifications.

Only the http and https protocols are supported, since debuginfod only
operates over HTTP(S).

The url attribute is unsupported; URL components must instead be passed
separately.

An added bearer attribute can supply OAuth2 bearer tokens
 in Base64
. This attribute
is mutually exclusive with username and password.

Daniel Thornburgh | dth...@google.com