Transport table and postmap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Transport table and postmap

Richard Stockton-2
Hi postfix people,

I am noticing an odd and somewhat disturbing thing on my FreeBSD
postfix installations.  When I redo my transport table,

        postmap /etc/postfix/transport

and then do a "strings /etc/postfix/transport.db" I see not only
the contents of the "transport" file, but also my entire master
password file including the password hashes!  That seems like a
very bad thing.  This occurs on all 8 of my FreeBSD postfix
installations.

On an almost identical postfix setup using RedHat instead of
FreeBSD, "strings /etc/postfix/transport.db" only includes the
contents of the "transport" file.

Note that the transport files are identical on all servers
whether FreeBSD or RedHat.

While normal users do not have access to the "transport.db" file,
it is still disturbing to see those password hashes in there.
I would appreciate any advice other than "convert everything to
RedHat" (although that may be what we do anyway).

TIA.
  - Richard

Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Wietse Venema
Richard Stockton:

> Hi postfix people,
>
> I am noticing an odd and somewhat disturbing thing on my FreeBSD
> postfix installations.  When I redo my transport table,
>
> postmap /etc/postfix/transport
>
> and then do a "strings /etc/postfix/transport.db" I see not only
> the contents of the "transport" file, but also my entire master
> password file including the password hashes!  That seems like a
> very bad thing.  This occurs on all 8 of my FreeBSD postfix
> installations.

Apparently, some SYSTEM LIBRARY Berkeley DB routine writes
uninitialized memory to file. Postfix does not write Berkeley DB
files directly.

Have you sent a bug report to the FreeSBD bugs database?

Solaris had a similar problem years ago with the tar(1) command.
Not nice if you were putting tar files on anonymous FTP servers.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

mouss-2
In reply to this post by Richard Stockton-2
Richard Stockton wrote:

> Hi postfix people,
>
> I am noticing an odd and somewhat disturbing thing on my FreeBSD
> postfix installations.  When I redo my transport table,
>
>     postmap /etc/postfix/transport
>
> and then do a "strings /etc/postfix/transport.db" I see not only
> the contents of the "transport" file, but also my entire master
> password file including the password hashes!  That seems like a
> very bad thing.  This occurs on all 8 of my FreeBSD postfix
> installations.
>
> On an almost identical postfix setup using RedHat instead of
> FreeBSD, "strings /etc/postfix/transport.db" only includes the
> contents of the "transport" file.
>
> Note that the transport files are identical on all servers
> whether FreeBSD or RedHat.
>
> While normal users do not have access to the "transport.db" file,
> it is still disturbing to see those password hashes in there.
> I would appreciate any advice other than "convert everything to
> RedHat" (although that may be what we do anyway).

I don't see the problem on FreeBSD 6.2-RELEASE (with db41-4.1.25_4
currently).

what versions do you use?


Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

d.hill
On Thu, 8 May 2008 at 21:18 +0200, [hidden email] confabulated:

> Richard Stockton wrote:
>> Hi postfix people,
>>
>> I am noticing an odd and somewhat disturbing thing on my FreeBSD
>> postfix installations.  When I redo my transport table,
>>
>>     postmap /etc/postfix/transport
>>
>> and then do a "strings /etc/postfix/transport.db" I see not only
>> the contents of the "transport" file, but also my entire master
>> password file including the password hashes!  That seems like a
>> very bad thing.  This occurs on all 8 of my FreeBSD postfix
>> installations.
>>
>> On an almost identical postfix setup using RedHat instead of
>> FreeBSD, "strings /etc/postfix/transport.db" only includes the
>> contents of the "transport" file.
>>
>> Note that the transport files are identical on all servers
>> whether FreeBSD or RedHat.
>>
>> While normal users do not have access to the "transport.db" file,
>> it is still disturbing to see those password hashes in there.
>> I would appreciate any advice other than "convert everything to
>> RedHat" (although that may be what we do anyway).
>
> I don't see the problem on FreeBSD 6.2-RELEASE (with db41-4.1.25_4
> currently).

Nor I with FreeBSD 7.0-RELEASE (same version of db as yours).

> what versions do you use?
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Zbigniew Szalbot-9
In reply to this post by mouss-2
Hello,

mouss pisze:

>> While normal users do not have access to the "transport.db" file,
>> it is still disturbing to see those password hashes in there.
>> I would appreciate any advice other than "convert everything to
>> RedHat" (although that may be what we do anyway).
>
> I don't see the problem on FreeBSD 6.2-RELEASE (with db41-4.1.25_4
> currently).


Neither is this a problem on FBSD 7.0-RELEASE!


--
Zbigniew Szalbot
www.lc-words.com

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Wietse Venema
Zbigniew Szalbot:

> Hello,
>
> mouss pisze:
>
> >> While normal users do not have access to the "transport.db" file,
> >> it is still disturbing to see those password hashes in there.
> >> I would appreciate any advice other than "convert everything to
> >> RedHat" (although that may be what we do anyway).
> >
> > I don't see the problem on FreeBSD 6.2-RELEASE (with db41-4.1.25_4
> > currently).

FreeBSD 6.2 does not use db41-4.1.25_4 by default.

It reproduces on FreeBSD 6.2 using the default Berkeley DB routines.
Password hashes are included only when a file is created by root.

Solaris had a similar problem years ago in the tar(1) command.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Wietse Venema
In reply to this post by Richard Stockton-2
Richard Stockton:

> Hi postfix people,
>
> I am noticing an odd and somewhat disturbing thing on my FreeBSD
> postfix installations.  When I redo my transport table,
>
> postmap /etc/postfix/transport
>
> and then do a "strings /etc/postfix/transport.db" I see not only
> the contents of the "transport" file, but also my entire master
> password file including the password hashes!  That seems like a
> very bad thing.  This occurs on all 8 of my FreeBSD postfix
> installations.

You may want to update the bug report.

In /usr/src/lib/libc/db/README, it says compile with -DPURIFY
otherwise it will write uninitialized memory to the file.

I just checked, and this fixes the problem. You have to add a line
with: #include <string.h> to /usr/src/lib/libc/db/db/hash/hash_buf.c

Tested on FreeBSD 6.2.

        Wietse

Inside /usr/src/lib/libc/db/db/hash/hash_buf.c, the function
__get_buf() contains little fragmets of code like this:

        if ((something = (whatever *) malloc(somesize)) == 0)
            error ...
    #ifdef PURIFY
            memset(something, 0xff, somesize);
    #endif

With PURIFY disabled valgrind complains:

valgrind --tool=memcheck -q --leak-check=yes --num-callers=12 postalias /tmp/aliases
==9084== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
==9084==    at 0x3C28632F: (within /lib/libc.so.6)
==9084==    by 0x3C277F86: __buf_free (in /lib/libc.so.6)
==9084==    by 0x3C2753D2: (within /lib/libc.so.6)
==9084==    by 0x80565F9: dict_db_close (dict_db.c:536)
==9084==    by 0x804C034: mkmap_close (mkmap_open.c:123)
==9084==    by 0x804A756: postalias (postalias.c:411)
==9084==    by 0x804B341: main (postalias.c:798)
==9084==  Address 0x3C2E3D56 is 34 bytes inside a block of size 4096 alloc'd
==9084==    at 0x3C038183: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==9084==    by 0x3C277BB9: __get_buf (in /lib/libc.so.6)
==9084==    by 0x3C275493: (within /lib/libc.so.6)
==9084==    by 0x805622D: dict_db_update (dict_db.c:314)
==9084==    by 0x804A6BB: postalias (postalias.c:378)
==9084==    by 0x804B341: main (postalias.c:798)

And many more complaints like this.
Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Richard Stockton-2
At 02:14 PM 5/8/2008, Wietse Venema wrote:

> > I am noticing an odd and somewhat disturbing thing on my FreeBSD
> > postfix installations.  When I redo my transport table,
> >
> >       postmap /etc/postfix/transport
> >
> > and then do a "strings /etc/postfix/transport.db" I see not only
> > the contents of the "transport" file, but also my entire master
> > password file including the password hashes!  That seems like a
> > very bad thing.  This occurs on all 8 of my FreeBSD postfix
> > installations.
>
>You may want to update the bug report.
>
>In /usr/src/lib/libc/db/README, it says compile with -DPURIFY
>otherwise it will write uninitialized memory to the file.
>
>I just checked, and this fixes the problem. You have to add a line
>with: #include <string.h> to /usr/src/lib/libc/db/db/hash/hash_buf.c

I have updated the FreeBSD bug report, although I note that the file
above does not exist on my machines.  I have a /usr/src/lib/libc/db/db
directory but nothing beyond that even though I have compiled custom
kernels on all the servers.  Looks to me like "hash" was never compiled.

Thanks again for your help.
  - Richard


Reply | Threaded
Open this post in threaded view
|

Re: Transport table and postmap

Wietse Venema
Richard Stockton:

> At 02:14 PM 5/8/2008, Wietse Venema wrote:
> > > I am noticing an odd and somewhat disturbing thing on my FreeBSD
> > > postfix installations.  When I redo my transport table,
> > >
> > >       postmap /etc/postfix/transport
> > >
> > > and then do a "strings /etc/postfix/transport.db" I see not only
> > > the contents of the "transport" file, but also my entire master
> > > password file including the password hashes!  That seems like a
> > > very bad thing.  This occurs on all 8 of my FreeBSD postfix
> > > installations.
> >
> >You may want to update the bug report.
> >
> >In /usr/src/lib/libc/db/README, it says compile with -DPURIFY
> >otherwise it will write uninitialized memory to the file.
> >
> >I just checked, and this fixes the problem. You have to add a line
> >with: #include <string.h> to /usr/src/lib/libc/db/db/hash/hash_buf.c
>
> I have updated the FreeBSD bug report, although I note that the file
> above does not exist on my machines.  I have a /usr/src/lib/libc/db/db
> directory but nothing beyond that even though I have compiled custom
> kernels on all the servers.  Looks to me like "hash" was never compiled.

You can install kernel sources without installing userland sources.
I usually install kernel and userland source, so I can build a
smaller kernel and apply bugfixes to kernel or userland.

        Wietse