Re: tftpd-hpa - insecure chroot()

[gremlin () gremlin ru]

On 2017-11-03 02:56:47 +0300, Dmitry V. Levin wrote:

> > #ifdef __CYGWIN__
> >  chdir("/");             /* Cygwin chroot() bug workaround */
> > #endif }

> Sorry, why do you think that
>  chdir(dir) == 0 && chroot(".") == 0
> is any worse than
>  chroot(dir) == 0 && chdir("/") == 0
> assuming that you have control over your signal handlers and can
> ensure they won't issue any chdir or chroot calls between these
> two calls?

Personally I just prefer the second sequence since first reading
`man 2 chroot` over 20 years ago: "This call does not change the
current working directory". So all my programs do change it just
immediately after chroot()ing. I've even made a Linux kernel patch
to force chroot() to do internal chdir("/"), but noone was really
interested. Those were the days...

Now, I've simply (and really accidentally, as all I wanted at that
time was to boot-up some hardware via PXE) noticed the tftpd server
running with "-s" ("secure") parameter without being chroot()ed.
This issue did cost me only some time, as that was in a properly
isolated VLAN, but I really prefer chroot()ed programs not to leave
their subdirectories, so I decided to have a look into the code and
the abovequoted piece appeared as the most suspicious for me.

The ${subj} in general and this issue in particular may deserve
more thoroughful exploration, but I'm very unlikely to do this in
the observable future, but even this notice may save (at least)
time to someone else.


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8

Attachment: _bin
Description: