[Pkg-samba-maint] Removing the NTDB packages from Buster onwards ?

[Lionel Debroux]

Hi,

To summarize a longer story: after fuzzing a number of DBM-type
databases available in the Debian archive, and finding issues in nearly
all of them, I noticed that the NTDB packages formed an island from
Stretch onwards:

# apt-cache rdepends libntdb1
libntdb1
Reverse Depends:
  libntdb-dev
  python-ntdb
  ntdb-tools
  libntdb1-dbg
# apt-cache rdepends libntdb-dev
libntdb-dev
Reverse Depends:
# apt-cache rdepends python-ntdb
python-ntdb
Reverse Depends:
  python-ntdb-dbg
# apt-cache rdepends ntdb-tools
ntdb-tools
Reverse Depends:
# apt-cache rdepends libntdb1-dbg
libntdb1-dbg
Reverse Depends:
  python-ntdb-dbg
# apt-cache rdepends python-ntdb-dbg
python-ntdb-dbg
Reverse Depends:


I reported the issues in the DBM-type databases to their respective
upstream maintainers.
For TDB, which crashes due to out of bounds accesses, Samba's Volker
Lendecke reacted very quickly: he provided 6 patches for TDB in less
than 12 hours, on a Sunday morning (!), and I restarted fuzzing on the
next day, 8 days ago.
For NTDB, which has a trivial nullptr deref, and otherwise crashes due
to controlled asserts in the library (easy DoS upon data corruption),
the situation is different. Quoting Volker Lendecke after I mentioned
that inciting distros to remove NTDB from future versions could be part
of the solution, without hurting many third-party packages (per the
above dep list):
"
I don't see Samba upstream to have the capacity to fix this code. Samba
does not use it. It was intended as the successor to tdb, but this never
materialized. So we removed it a few years ago. It's really up to
debian to just dump it.
"

Hence this e-mail, a bit less than week later :)


If you want to fix the NTDB code for Jessie (which still uses it) and
Stretch on the distro side, I can send the set of testcases.
The trivial nullptr deref, which I found by chance, is:

valgrind --tool=memcheck --malloc-fill=0x55 --free-fill=0xAA
--trace-children=yes --leak-check=no ntdbtool emptydb create
==782== Memcheck, a memory error detector
==782== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==782== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==782== Command: ntdbtool emptydb create
==782==
ntdb:emptydb:IO Error:ntdb_open: could not open file emptydb: No such
file or directory
Could not open emptydb: No such file or directory
==782== Invalid read of size 1
==782==    at 0x4C2FDB2: __strlen_sse2 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==782==    by 0x4E50237: alloc_ntdb (open.c:473)
==782==    by 0x4E50237: ntdb_open (open.c:510)
==782==    by 0x402AAC: ??? (in /usr/bin/ntdbtool)
==782==    by 0x402731: ??? (in /usr/bin/ntdbtool)
==782==    by 0x5088F29: (below main) (libc-start.c:310)
==782==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==782==
==782==
==782== Process terminating with default action of signal 11 (SIGSEGV)
==782==  Access not within mapped region at address 0x0
==782==    at 0x4C2FDB2: __strlen_sse2 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==782==    by 0x4E50237: alloc_ntdb (open.c:473)
==782==    by 0x4E50237: ntdb_open (open.c:510)
==782==    by 0x402AAC: ??? (in /usr/bin/ntdbtool)
==782==    by 0x402731: ??? (in /usr/bin/ntdbtool)
==782==    by 0x5088F29: (below main) (libc-start.c:310)
==782==  If you believe this happened as a result of a stack
==782==  overflow in your program's main thread (unlikely but
==782==  possible), you can try to increase the size of the
==782==  main thread stack using the --main-stacksize= flag.
==782==  The main thread stack size used in this run was 8388608.
==782==
==782== HEAP SUMMARY:
==782==     in use at exit: 0 bytes in 0 blocks
==782==   total heap usage: 4 allocs, 4 frees, 1,682 bytes allocated
==782==
==782== For a detailed leak analysis, rerun with: --leak-check=full
==782==
==782== For counts of detected and suppressed errors, rerun with: -v
==782== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Erreur de segmentation


Stretch could be easily fixed without breaking in-tree users, but I have
no clue whether Debian ever removes packages from distro releases, even
if they're unmaintained upstream and contain unfixed security issues
(just easy DoS, but still).


security at debian.org is already aware of my findings in TDB, NTDB and the
other DBM-type databases, which is why I didn't Cc them here: I don't
want to unnecessarily add to their workload.


Best regards,
Lionel Debroux.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20180313/00b9fbed/attachment-0001.sig>