public inbox for
 help / color / mirror / Atom feed
* runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ?
@ 2022-07-11 16:40 Milian Wolff
  2022-07-26 15:28 ` Mark Wielaard
  0 siblings, 1 reply; 5+ messages in thread
From: Milian Wolff @ 2022-07-11 16:40 UTC (permalink / raw)
  To: elfutils-devel

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

Hey there,

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?


PS: eu-elflint reports this for the broken DSOs e.g.:
$ eu-elflint
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?
Milian Wolff

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-08-28  6:41 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-11 16:40 runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ? Milian Wolff
2022-07-26 15:28 ` Mark Wielaard
2022-07-27 11:38   ` Milian Wolff
2022-07-28 16:41     ` Mark Wielaard
2022-08-28  6:41       ` Jacob Burkholder

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).