Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 5 Jul 2000, Dr. Bodo Zimmermann wrote:

> In a CGI-Script (named gpg.pl, e.g.) I have called:
>
> system "gpg -se -r dozi /tmp/TEST";
>
> After https://dozi2/cgi-bin/gpg.pl
>
> I got in error_log des httpd:
>
> gpg: Warning: using insecure memory!
> gpg: fatal: ~/.gnupg: can´t create directory: no such file or directory
> secmem usage: 0/0 bytes in 0/0 blocks of pool 0/16384

First of all, "chmod +s /usr/local/bin/gnupg"..
Then it will use secure memory.
Can't find or create ~/.gnupg because what's '~' ($HOME)?
What user is this CGI running as? Give that user a home with a ~/.gnupg
directory or something... Where were you planning on storing the keys
if not there? What about a passphrase?

> What should I do in order to get /tmp/TEST.gpg
> which I got when running the CGI script directly from command line?

Well, you were running as yourself on the command line... and you HAVE
a ~/.gnupg directory.

> P.S. My idea is, to make an "upload" of plain text via an SSL secured browser
> an encrypt the uploaded file /tmp/TEST immediately after the upload, then
> deleting the plain file /tmp/TEST
>
> I know there is a securty hole, but as long as WIN-gnupg doesn`t work ......

Geez.. that's about as bad a hole as they come...
Look at the permissions on the /tmp directory...
At least make a dedicated, restricted directory for this TEST file.
Better yet, don't write it to disk at all... GnuPG is perfectly
happy taking a pipe from stdin. Keep the file contents in RAM
and print it to GnuPG's standard input.

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue <mailto:billy@dadadada.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Made with pgp4pine 1.75

iD8DBQE5Y2CD+2VvpwIZdF0RAkrOAKCNARyv1cTv/h/w2ps2by3FTpgqpQCfSS3g
12tEdEpxrg5lNYAqpUdb5M4=
=JOed
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 5 Jul 2000, Billy Donahue wrote:

> On Wed, 5 Jul 2000, Dr. Bodo Zimmermann wrote:
>
> > In a CGI-Script (named gpg.pl, e.g.) I have called:
> >
> > system "gpg -se -r dozi /tmp/TEST";
> >
> > After https://dozi2/cgi-bin/gpg.pl
> >
> > I got in error_log des httpd:
> >
> > gpg: Warning: using insecure memory!
> > gpg: fatal: ~/.gnupg: can´t create directory: no such file or directory
> > secmem usage: 0/0 bytes in 0/0 blocks of pool 0/16384
>
> First of all, "chmod +s /usr/local/bin/gnupg"..
> Then it will use secure memory.
> Can't find or create ~/.gnupg because what's '~' ($HOME)?
> What user is this CGI running as? Give that user a home with a ~/.gnupg
> directory or something... Where were you planning on storing the keys
> if not there? What about a passphrase?
>

Hmm, SUID root (chmod +s) can be dangerous as recent exploits have
shown. Adding no-secmem-warning to your .gnupg/options file is a valid
alternative for getting rid of the secure memory message.

> > What should I do in order to get /tmp/TEST.gpg
> > which I got when running the CGI script directly from command line?
>
> Well, you were running as yourself on the command line... and you HAVE
> a ~/.gnupg directory.
>
> > P.S. My idea is, to make an "upload" of plain text via an SSL secured browser
> > an encrypt the uploaded file /tmp/TEST immediately after the upload, then
> > deleting the plain file /tmp/TEST
> >
> > I know there is a securty hole, but as long as WIN-gnupg doesn`t work ......
>
> Geez.. that's about as bad a hole as they come...
> Look at the permissions on the /tmp directory...
> At least make a dedicated, restricted directory for this TEST file.
> Better yet, don't write it to disk at all... GnuPG is perfectly
> happy taking a pipe from stdin. Keep the file contents in RAM
> and print it to GnuPG's standard input.
>

I have to agree with this all the way though... ;-)


Stefan Suurmeijer


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5Y3lbwVt5lhn5J64RArl9AKCRGC9Q631Mb+zAnSFtBSSJaSs/ugCfZDpB
J6tE9BtwVxChg09zRp4ljf0=
=ciVz
-----END PGP SIGNATURE-----

On Wed, 5 Jul 2000, L. Sassaman wrote:

> On Wed, 5 Jul 2000, Stefan Suurmeijer wrote:
>
> > Hmm, SUID root (chmod +s) can be dangerous as recent exploits have
> > shown. Adding no-secmem-warning to your .gnupg/options file is a valid
> > alternative for getting rid of the secure memory message.
>
> Do you own a car? What would you do if a mechanic told you "Hey, you have
> this "brake pad" warning light on your dash. You want I should remove the
> light for you?"

Wow, if you only explained that to me earlier, would have saved me a lot
of traffic tickets ;-). And yes, it would help me get rid of that annoying
light.

>
> Sheesh. no-secmem-warning exists for cases when you simply can't make gpg
> suid. But in those cases it shouldn't be treated as secure.
> >
>

Personally, I'd rather drive without brakes in my own backyard (and
unfortunately I do know some of my servers better than my backyard) than
having the brakes fixed at the expense of the door locks. Not much use in
having excellent brakes if your car is stolen.
Anyway, advising people to use secure memory by using suid is great, but
make sure you warn them that for some kernel versions they might be
opening themselves up to other risks. There are people out there that
don't know that.

Stefan

On Wed, 5 Jul 2000, Stefan Suurmeijer wrote:

> Anyway, advising people to use secure memory by using suid is great, but
> make sure you warn them that for some kernel versions they might be
> opening themselves up to other risks. There are people out there that

From my understanding about the problem this code (from 1.0.1h)

if( setuid( uid ) || getuid() != geteuid() || !setuid(0) )
log_fatal("failed to reset uid: %s\n", strerror(errno));

is a safeguard against the faulty setcap implementation. The
term "|| !setuid(0)" should always we false unless someone tries
the setcap exploit in whichcase the setuid(0) will succeed. Note,
this code is note used when running as root.

Werner

--
Werner Koch OpenPGP key 621CC013
OpenIT GmbH tel +49 211 239577-0
Birkenstr. 12 email wk@OpenIT.de
D-40233 Duesseldorf http://www.OpenIT.de

On Thu, 6 Jul 2000, Werner Koch wrote:

> >From my understanding about the problem this code (from 1.0.1h)
>
> if( setuid( uid ) || getuid() != geteuid() || !setuid(0) )
> log_fatal("failed to reset uid: %s\n", strerror(errno));
>
> is a safeguard against the faulty setcap implementation. The
> term "|| !setuid(0)" should always we false unless someone tries
> the setcap exploit in whichcase the setuid(0) will succeed. Note,
> this code is note used when running as root.
>

Hmm. Am I reading this wrong? I'm no C expert, but shouldn't the negation
be removed ( || setuid(0) as opposed to || !setuid(0)) ? If the setcap
exploit is used and setuid(0) succeeds, you want the if loop to be TRUE,
right? I just tried to implement the sendmail solution (see below) into
secmem.c (BTW, this didn't include the above check, although I downloaded
my current version just two weeks ago. When did 1.0.1h become available?)


---> snip

The sendmail patch attempts a setuid(0) after a setuid(getuid());
under normal circumstances this should fail (unless of course
the real uid is root). If this setuid(0) succeeds, then the>
kernel has failed to properly give up permissions and sendmail>
will refuse to continue running.


---> endsnip

> --
> Werner Koch OpenPGP key 621CC013
> OpenIT GmbH tel +49 211 239577-0
> Birkenstr. 12 email wk@OpenIT.de
> D-40233 Duesseldorf http://www.OpenIT.de
>
>

Stefan


==========================================
Stefan Suurmeijer
Network Specialist
University of Groningen
tel: (+31) 50 363 3423
fax: (+31) 50 363 7272
E-mail (business): s.m.suurmeijer@let.rug.nl
E-mail (private): stefan@symbolica.nl
==========================================

Quis custodiet ipsos custodes? (Who'll watch the watchmen?) - Unknown

Stefan Suurmeijer <stefan@symbolica.nl> writes:

> Hmm. Am I reading this wrong? I'm no C expert, but shouldn't the negation
> be removed ( || setuid(0) as opposed to || !setuid(0)) ? If the setcap
> exploit is used and setuid(0) succeeds, you want the if loop to be TRUE,
> right?

setuid returns 0 if it succeeds.

--
Alan Shutko <ats@acm.org> - In a variety of flavors!
127 days, 22 hours, 8 minutes, 1 seconds till we run away.
Silly Wabbit, QWKs are for kids. - Wave-IT!!!