On 10/18/2009 10:32 PM, Jan Kratochvil wrote:
On Fri, 16 Oct 2009 12:39:33 +0200, Jiri Moskovcak wrote:
> On 10/16/2009 11:05 AM, Jan Kratochvil wrote:
>> On Fri, 16 Oct 2009 10:36:04 +0200, Jiri Moskovcak wrote:
>>> Or if we don't have debuginfo then we shouldn't even try to get bt?
>>
>> I think ABRT should avoid using debuginfo even if it is installed as it may be
>> performance-costly for the client machine and the retrace server can take care
>> of it better incl. by its use of entries caching across reporting machines.
>>
>> But I still miss:
>>
>> * Facts why ABRT is still stepping around the use of external retrace server.
>
> 1. How would you imagine it to work for ordinary desktop users,
> should they install their own private retrace server or send the
> cores somewhere? (neither is possible)
No cores are being sent anywhere. My followup mail
https://fedorahosted.org/pipermail/crash-catcher/2009-October/000056.html
contains the line
(eu-unstrip -n --core=`echo ./core.*`; echo; gdb -nx -ex "set debug-file-directory
/_N" -ex "core-file `echo ./core.*`" -ex bt -ex q) 2>/dev/null | nc
host1.dyn.jankratochvil.net 7221
so you can check yourself
(eu-unstrip -n --core=`echo ./core.*`; echo; gdb -nx -ex "set debug-file-directory
/_N" -ex "core-file `echo ./core.*`" -ex bt -ex q) 2>/dev/null
* sends no secure info
* sends no more info than will be in the final public bugreport
* contant has size 1-2KB (compared to the excessive size of core files)
Sample output being sent out of client is provided at the bottom of this mail.
Sorry, I didn't pay enough attention to this, as this is more Denys's
part of work in abrt. This way it sounds good.
>> * Decision if parameters and local variables should / should not be dumped.
>> (such as "bt vs. bt full", there are some changes of it in ABRT
changelog)
>> - Possible security disclosure.
>> + Better debuggability
>> (still not perfect, sometimes even a full core is not enough and one needs
>> a reproducer to be able to fix the bug).
>> (My current retrace client/server draft would need to be extended for it.)
>
> I vote for dumping the variables, but we need to change the gui and
> make it easier for user to see and remove sensitive data from the BT.
Currently the retrace server is not suitable for dumping the
parameters/variables (and while possible it is not so easy to extend it for
such functionality).
Nevermind retrace without parameters/variables is better then no retrace :)
Still even if the retrace server would be extended for such remote
parameters/local variables dumping it will probably have the same security
level as what suggested Denys Vlasenko:
https://fedoraproject.org/wiki/Features/DebuginfoFS
* 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
bugzilla.redhat.com 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:
http://dwarf.freestandards.org/Dwarf3.pdf
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 server? You
could probably enlighten us in person.
Using DebuginfoFS without downloading always the whole .debug file is
probably
best to be dependent on .debug_gnu_index under development:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
> 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 ("password")
from the core file hiding from user it can be sensitive:
#1 harmless (s=0x7fffffffd0e0 "\332\313\331\331\335\305\330\316") at x.c:13
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.
Thanks for the discussion, currently I do not have such retrace server if the
parameters / local variables should be present in the dumps.
Regards,
Jan
Thanks,
Jirka