On Mon, 19 Oct 2009 11:43:08 +0200, Jiri Moskovcak wrote:
On 10/18/2009 10:32 PM, Jan Kratochvil wrote:
> Still even if the retrace server would be extended for such
> parameters/local variables dumping it will probably have the same security
> level as what suggested Denys Vlasenko:
> * There is no risk of sending information client -> retrace server.
> * There is a risk retrace server -> client will send back malicious debuginfo.
> Currently the debuginfo installed by yum at the client is signed by the
> Fedora project keys. The retrace server -> client protocol content does not
> have such easy security signature.
> * The information sent from client is put as a public bug entry into
where the malicious retrace server can read it back from.
> * debuginfo can contain arbitrary Turing-complete DWARF expressions executed
> by the "virtual machine" in GDB, language described at:
> 2.5 DWARF Expressions; page 14 (26/267)
I don't get this (probably becouse of my lack of knowledge of
dwarfs, elfs, etc ...), why would retrace server send any debuginfo
back to client? I thought the debuginfo (from signed packages) will
live on retrace server and the client just get the backtrace (and
even this seems unnecessary). Or are you talking about debuginfofs
You said you do not trust the retrace server as you cannot send the whole core
file client->retrace server. The retrace server needs various chunks of the
core file to display the backtrace. As the client does not have the debuginfo
it does not know which core chunks are needed for the backtrace. If the
client will send arbitrary chunks of the core as requested by the retrace
server it can disclose any secure information the retrace server would request.
The client must know which info to send to the server. For the
parameters/variables-less backtrace it knows it must send the PC (program
counter) addresses. But determining which memory content will be required to
print the parameters/variables requires general debuginfo access.
debuginfo (.debug file) contains a bytecode, it is like a Java .class file.
It cannot do any harm to your system (it has no filesystem access etc.) but
malicious debuginfo can intelligently access anything from the core file and
present arbitrarily encoded=hidden information in the backtrace.
> > make it easier for user to see and remove sensitive data
from the BT.
> If the provided debuginfo is not secure (DebuginfoFS) its malicious DWARF
> expression can easily encode the retrieved security information
> from the core file hiding from user it can be sensitive:
> #1 harmless (s=0x7fffffffd0e0 "\332\313\331\331\335\305\330\316") at
> Have you recognized this is "password" ^ 0xaa?
Yes, I' aware of this, but in this case the only solution I can
think of is to not dump the variables.
This is a political decision of trust. On Fedora system you already must
trust the binaries you used for the system installation and you trust any
binary rpm updates signed by fedoraproject.org
For the backtrace you must have trust in the debuginfo content.
* The full rpm-signed *-debuginfo.arch.rpm is too big to transfer to client.
* Client must not send any core file content before it was approved by the
user. User must see the backtrace based on the core memory formatting done
by trusted parts of debuginfo.
=> The only way out is a trusted retrace server based on fedoraproject.org
Which technical way to choose (gdbserver protocol from core file, DebuginfoFS
with fixed/improved GDB debuginfo reading etc.) is a secondary question.
The previous paragraph applies exactly the same way to DebuginfoFS server.
Another question if such complicated discussions should be made. Majority of
the Fedora users installs proprietary software on their machine and so they
already gave up their system security in a much significant way than some
trust in retrace server. The few users keeping their system in trust only
may not have any problem downloading full rpm-signed
*-debuginfo.arch.rpm to the client (as myself).
And also I find it invalid to think a user is able to decide if some backtrace
contains secure information, this is technically very complicated decision.
Various private keys looking as binary data passed as parameters etc.