How to protect a file from debugging

How to protect a file from debugging

[Oliver Welter]

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

Hi List,

sorry if this is a stupid question but I am not very familiar with gdb ;)

I am planing a security application and gdb is causing some "troubles".

Can someone point me to some infos or shortly explain me if there is a
way to protect a program from attaching to it? I must either prevent gdb
 (or similar software) from attaching to a process or at least detect
the attach and send a terminate signal to the application.

best regards

Oliver
-- 
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to protect a file from debugging

[Tavis Ormandy]

On Mon, Jun 11, 2007 at 10:16:33AM +0200, Oliver Welter wrote:
> Hi List,
> 
> sorry if this is a stupid question but I am not very familiar with gdb ;)
> 
> I am planing a security application and gdb is causing some "troubles".
> 
> Can someone point me to some infos or shortly explain me if there is a
> way to protect a program from attaching to it? I must either prevent gdb
>  (or similar software) from attaching to a process or at least detect
> the attach and send a terminate signal to the application.
> 

The short answer is no, any tricks you attempt to use to prevent
ptrace() can be defeated (some more easily than others), however if you
explain what the "troubles" are there may be a better solution.

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------

Re: How to protect a file from debugging

[Oliver Welter]

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

Hi Tavis

> The short answer is no, any tricks you attempt to use to prevent
> ptrace() can be defeated (some more easily than others), however if you
> explain what the "troubles" are there may be a better solution.
> 
damn ;)

Ok here is what I am planing:

I have an application, lets say a simple text editor, that is used to
read/write sensitive information.
Now I start gdb, attach it to the process and call "gcore" which - for
my understanding - dumps the entire memory of the process to a file. So
the core dump reveals my secret data.

What I want to do is, to either prevent gdb from attaching and capturing
the memory or at least find a way to recognize when a program attaches
another. I am a noob regarding the internal system structure, so I dont
know exactly what gdb does to attach to a program, but I guess there is
a syscall or similar that is used to pass the memory location to gdb and
if I block/supervise that, I might find a way around....

Oliver

-- 
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to protect a file from debugging

[Andreas Schwab]

Oliver Welter <mail@oliwel.de> writes:

> Ok here is what I am planing:
>
> I have an application, lets say a simple text editor, that is used to
> read/write sensitive information.
> Now I start gdb, attach it to the process and call "gcore" which - for
> my understanding - dumps the entire memory of the process to a file. So
> the core dump reveals my secret data.

Why is that a problem?  You are one only reading the same secret data
that you just entered yourself in the editor.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: How to protect a file from debugging

[Oliver Welter]

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

>> I have an application, lets say a simple text editor, that is used to
>> read/write sensitive information.
>> Now I start gdb, attach it to the process and call "gcore" which - for
>> my understanding - dumps the entire memory of the process to a file. So
>> the core dump reveals my secret data.
> 
> Why is that a problem?  You are one only reading the same secret data
> that you just entered yourself in the editor.
> 

Before the editor can access the data, its integrity is checked and the
editor has certain properties, e.g. not allowing to store the data
outside of an encrypted filesystem. So if an unchecked application can
gather the data, it might leave the system.

Oliver

-- 
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to protect a file from debugging

[Tavis Ormandy]

On Mon, Jun 11, 2007 at 11:37:40AM +0200, Oliver Welter wrote:
> >> I have an application, lets say a simple text editor, that is used to
> >> read/write sensitive information.
> >> Now I start gdb, attach it to the process and call "gcore" which - for
> >> my understanding - dumps the entire memory of the process to a file. So
> >> the core dump reveals my secret data.
> > 
> > Why is that a problem?  You are one only reading the same secret data
> > that you just entered yourself in the editor.
> > 
> 
> Before the editor can access the data, its integrity is checked and the
> editor has certain properties, e.g. not allowing to store the data
> outside of an encrypted filesystem. So if an unchecked application can
> gather the data, it might leave the system.
> 
> Oliver

Are you already using mlock()? If so presumably you're starting setuid
root, and the kernel will already be enforcing a secure execution
environment, preventing ptrace(), so you dont have to worry about this.

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------