Hello, Many thanks for your bug report, I'll try to fix this problem by adding a few strncpy() where needed in the next days, to provide a better fix. Regards, ludovic
Le 26 mai 2015 02:11:28 CEST, "Frédéric Brière" <fbri...@fbriere.net> a écrit : >Package: xjdic >Version: 24-9 >Severity: normal >Tags: upstream patch > >[ Although buffer overflows are often regarded as security bugs, I'm >filing this bug with normal severity, on the advice of the security >team. ] > > >There are several possible buffer overflows throughout the xjdic code >(at least in the client). The easiest one to trigger is by reading >from >/dev/null: > > $ xjdic_sa < /dev/null > /dev/null > *** buffer overflow detected ***: /usr/bin/xjdic_sa terminated > [...] > >This is due to xjdic usually not checking getchar() for EOF (if not >storing its return value outright in an unsigned char), thus appending >it to its output buffer in an infinite loop. > > >The one that prompted me to file this bug report occurs when reading a >romaji string of 10 kana or more: simply typing "@aaaaaaaaaa" will >crash >the client. (Only romaji is affected; inputting kana directly works >fine.) This is due to tempout[] being woefully short at 80 bytes; I'm >attaching a patch that pushes that limit far enough for any EDICT >entry. >(This isn't an actual fix; the client will still crash, only it will >take an unusually long input string for this to happen.) > > >-- System Information: >Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') >Architecture: i386 (x86_64) >Foreign Architectures: amd64 > >Kernel: Linux 3.16.0-4-amd64 (SMP w/3 CPU cores) >Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) >Shell: /bin/sh linked to /bin/dash >Init: sysvinit (via /sbin/init)
