[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