Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
The issue can be fixed using 2 upstream patches:

https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch

https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch

applied to sources in this order, after recompile no segmentation faults
were encountered.

those patches can be squashed for convenience to single patch.


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
Attached full bt log of gdb and valgrind log with debug-symbols package
installed

Unfortunately can't test this with other applications (ffmpeg ...)


bt.tar.gz
Description: application/gzip


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
Unfortunately freeswitch (the actual application) is not available in deb
archive.

How can I provide addition info on this issue?


Bug#826646: Incorrect handling with initial_cwd variable

2016-06-12 Thread Серж ИвановЪ
I would like to point out that this bug also affects current debian stable
exim package.
To verify one would need to examine exim source package for debian jessie

apt-get source exim4
grep -A 8 "To be safe: change the working directory to"
./exim4-4.84.2/src/exim.c

"""
/* To be safe: change the working directory to /. */
if (Uchdir("/") < 0)
  {
perror("exim: chdir `/': ");
exit(EXIT_FAILURE);
  }

/* Store the initial cwd before we change directories */
if ((initial_cwd = getcwd(NULL, 0)) == NULL)
"""

This is exactly the same error as in oldstable, we are doing chroot BEFORE
initial_cwd handling

​So this upstream patch is also applicable
https://github.com/Exim/exim/commit/3de973a29de6852d61ba9bf1845835d08ca5a5ab#diff-6e46fb11179cb7da978360d317a92ee0

Do I need to file a bug report for debian jessie (exim4-4.84) version?

Thanks


Bug#826646: Incorrect handling with initial_cwd variable

2016-06-09 Thread Серж ИвановЪ
Our friends at Ubuntu released initial_cwd security patch correctly from
the start.

Here is a relevant change log:
http://changelogs.ubuntu.com/changelogs/pool/main/e/exim4
/exim4_4.82-3ubuntu2.1/changelog

"debian/patches/CVE-2016-1531-4.patch: delay chdir(/) until we opened the
main config."

Some feedback would be greatly appreciated.


Bug#826646: Incorrect handling with initial_cwd variable

2016-06-07 Thread Серж ИвановЪ
Package: exim4
Priority: standard
Version: 4.80

Currently exim4 debian package handles CWD parameter not correctly.

This fix introduced security patch to store CWD into additional variable
named initial_cwd and it was applied in debian exim packages.
https://bugs.exim.org/show_bug.cgi?id=1805

Before this security fix (Bug 1805), upstream introduced some additional
changes to CWD handling code, this fix was not applied by debian package
maintainers.
https://github.com/Exim/exim/commit/3de973a29de6852d61ba9bf1845835d08ca5a5ab#diff-6e46fb11179cb7da978360d317a92ee0

Current behavior overrides CWD BEFORE any CWD handling could occur.

Uchdir("/") occurs before initial_cwd reads current working directory.

This bug applies to exim in stable and oldstable distribution.

This bug can be reproduced by adding this code "warn logwrite =
$initial_cwd" into acl_not_smtp_start config section

While sending email using plain sendmail, exim4 mail.log has to contain
initial working directory of calling process but instead it contains
already chrooted patch "/"

This is a serious bug, it breaks logic of many spam handling software and
should be fixed soon.


Bug#818897: Exim4 change CWD string to /

2016-06-05 Thread Серж ИвановЪ
On Thu, 21 Apr 2016 19:30:15 +0200 Andreas Metzler  wrote:
> On 2016-04-20 Roman Bulakh  wrote:
> > On 2016-03-27 Andreas Metzler  wrote:
> >> On 2016-03-21 Roman Bulakh  wrote:
> >>> Package: exim4
> >>> Version: 4.80-7+deb7u2
>
> >>> After updates exim to version 4.80-7+deb7u2 exim.c change CWD dir to /
> >>> on startup.
> [...]
> >> /usr/share/doc/exim4-base/changelog.Debian.gz
> >> exim4 (4.80-7+deb7u2) wheezy-security; urgency=high
> >>   * 88_CVE-2016-1531.diff:
> >> [...]
> >> + Exim changes it's working directory to / right after startup.
> >> [...]
> >>   * 89_01_only_warn_on_nonempty_environment.diff,
> >> 89_02_Store-the-initial-working-directory.diff: Upstream followups
on the
> >> CVE fix (Thanks, Heiko Schlittermann!):
> >> [...]
> >> + Store the initial working directory and make it available in the
new
> >>   expansion variable $initial_cwd.
>
>
> >> Sadly I made an error with the latter patch, but it is going to be
fixed
> >> in the next point release. See , you
can
> >> already grab 4.80-7+deb7u3 directly from the mirrors.
> >> http://ftp.at.debian.org/debian/pool/main/e/exim4/
> [...]
>
> > Problem is not fixed. I have exim 4.80-7+deb7u3 but cwd still "cwd=/"
>
> Please re-read my comment. I did not say exim stopped changing to / but
> "Store the initial working directory and make it available in the new
> expansion variable $initial_cwd.".
>
> You'll need to change your config.
>
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>
>

Using this code "warn log_message = $initial_cwd" in acl_not_smtp yields
"2016-06-05 13:16:51 1b9V6x-00059W-3B U=root Warning: /"
as apposed to correct behavior,

can you clarify needed config changes, what are we missing here?


Bug#819203: xinetd init script does not contain status option

2016-03-24 Thread Серж ИвановЪ
Package: xinetd
Version: 1:2.3.14-7.1+deb7u1

In debian 7, xinetd init script does not contain status option
this is mandatory for saltstack for example, it fails to get status of
service

for a fix init script should be updated with following lines:

status)
  status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
  ;;