[ldapvi] [PATCH] 'ldapvi --in' issue with base64 encoded dn when (len_dn % 3) == 0

ktetzl debian at tetzco.de
Thu Sep 7 16:22:07 CEST 2023


Package: ldapvi
Version: 1.7-10+b6
Severity: important
Tags: patch upstream
X-Debbugs-Cc: David Lichteblau <david at lichteblau.com>, ldapvi at lists.askja.de

'ldapvi --in' has a bug in ldapvi/base64.c read_base64(..) that cause a 
missing
'\0' terminator when decoding base64 encoded DNs which don't end with 
padding
(i.e. when (len_decoded_dn % 3) == 0).

The attached patch contains a fix for the issue.


Recipe to reproduce the issue:

Example LDIF file (test.ldif):
--
# dn of 'ou=abc,dc=example,dc=com' (length 24) gets base64 encoded
# without padding
dn:: b3U9YWJjLGRjPWV4YW1wbGUsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--

Running:

VISUAL=cat ldapvi --in --add test.ldif 2>/dev/null

results in the following output (note the 'sZGM9Y29t' suffix after 'add
ou=abc,dc=example,dc=com'):
--
# -*- coding: utf-8 -*- vim:fileencoding=utf-8:
# http://www.lichteblau.com/ldapvi/manual#syntax

add ou=abc,dc=example,dc=comsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--

-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ldapvi depends on:
ii libc6 2.37-7
ii libcrypt1 1:4.4.36-2
ii libglib2.0-0 2.77.2-1
ii libldap-2.5-0 2.5.13+dfsg-5
ii libpopt0 1.19+dfsg-1
ii libreadline8 8.2-1.3
ii libtinfo6 6.4+20230625-2

ldapvi recommends no packages.

ldapvi suggests no packages.

-- no debconf information

-------------- next part --------------
From 87cfd72067e927665ae819c6d0e3d1aa970777a2 Mon Sep 17 00:00:00 2001
From: ktetzlaff <debian at tetzco.de>
Date: Thu, 7 Sep 2023 11:59:34 +0200
Subject: [PATCH] Fix 'ldapvi --in' issue with base64 encoded dn when (len_dn %
 3) == 0

Fix 'ldapvi --in' bug in ldapvi/base64.c read_base64(..) that cause a missing
'\0' terminator when decoding base64 encoded DNs which don't end with
padding (i.e. when (len_decoded_dn % 3) == 0).

Recipe to reproduce the issue without the fix:

Example LDIF file (test.ldif):
--
# dn of 'ou=abc,dc=example,dc=com' (length 24) gets base64 encoded
# without padding
dn:: b3U9YWJjLGRjPWV4YW1wbGUsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--

Running:

    VISUAL=cat ldapvi --in --add test.ldif 2>/dev/null

results in the following output (note the 'sZGM9Y29t' suffix after 'add
ou=abc,dc=example,dc=com'):
--
# -*- coding: utf-8 -*- vim:fileencoding=utf-8:
# http://www.lichteblau.com/ldapvi/manual#syntax

add ou=abc,dc=example,dc=comsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--
---
 ldapvi/base64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ldapvi/base64.c b/ldapvi/base64.c
index b21ded7..755da59 100644
--- a/ldapvi/base64.c
+++ b/ldapvi/base64.c
@@ -278,6 +278,8 @@ read_base64(
 		 */
 		if (state != 0)
 			return (-1);
+		/* Make sure that target is terminated with nul byte. */
+		target[tarindex] = '\0';
 	}
 
 	return (tarindex);
-- 
2.40.1




More information about the ldapvi mailing list