[Bug 1399580] New: CVE-2016-1251 perl-DBD-MySQL:
Use after free when using prepared statements
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1399580
Bug ID: 1399580
Summary: CVE-2016-1251 perl-DBD-MySQL: Use after free when
using prepared statements
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: hhorak(a)redhat.com, jorton(a)redhat.com,
jplesnik(a)redhat.com,
perl-devel(a)lists.fedoraproject.org,
perl-maint-list(a)redhat.com, ppisar(a)redhat.com,
psabata(a)redhat.com
A use after free vulnerability when using prepared statements was found in
DBD::mysql. Function dbd_st_fetch() via Renew() can reallocate output buffer
for mysql_stmt_fetch() call, but it does not update pointer to that buffer in
imp_sth->stmt structure initialized by mysql_stmt_bind_result() function, which
leads to use after free in any mysql function which access imp_sth->stmt
structure.
This vulnerability is present in all releases at least back to versions 3.0 of
the driver, which were released in 2005.
Upstream patch:
https://github.com/perl5-dbi/DBD-mysql/commit/3619c170461a3107a258d1fd2d0...
References:
http://seclists.org/oss-sec/2016/q4/536
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 3 months
[Bug 1371942] New: use base broken by update to perl 5.22.2
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1371942
Bug ID: 1371942
Summary: use base broken by update to perl 5.22.2
Product: Fedora
Version: 23
Component: perl
Severity: medium
Assignee: jplesnik(a)redhat.com
Reporter: steve.bz(a)yewtc.demon.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
External Bug ID: Debian BTS 833030
Description of problem:
...
use base qw{My::Module}
...
causes:
Base class package 'My::Module' is empty
Version-Release number of selected component (if applicable):
5.22.2
How reproducible:
Every time
Steps to Reproduce:
1. Add "use base module_name" to source file
2. compile
3.
Actual results:
as above
Expected results:
it complies ok (it did before security update).
Additional info:
This is essentially the same debian bugreport 833030, but there the version of
perl is 5.14.
I guess the same comments apply, I'm really only submitting this as a bug here
because others might be looking.
I used the work around of adding "use My::Module".
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 3 months
[Bug 1402787] New: Should default SSL_ca_file to global store
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1402787
Bug ID: 1402787
Summary: Should default SSL_ca_file to global store
Product: Fedora
Version: rawhide
Component: perl-IO-Socket-SSL
Severity: medium
Assignee: paul(a)city-fan.org
Reporter: brian(a)interlinx.bc.ca
QA Contact: extras-qa(a)fedoraproject.org
CC: jose.p.oliveira.oss(a)gmail.com, paul(a)city-fan.org,
perl-devel(a)lists.fedoraproject.org,
perl-maint-list(a)redhat.com, ppisar(a)redhat.com,
qe-baseos-security(a)redhat.com
I suspect this issue applies to Fedora also.
+++ This bug was initially created as a clone of Bug #1402588 +++
Description of problem:
When writing/using a perl script that wants to use SSL via perl-IO-Socket-SSL I
am required to point the library at the default global certificate store. I
shouldn't have to do that as a default behavioura.
Version-Release number of selected component (if applicable):
perl-IO-Socket-SSL-1.94-3.el7.noarch
How reproducible:
100%
Steps to Reproduce:
1. Write a perl script to make an SSL connection but don't set SSL parameters
Actual results:
connect failed: Unable to start TLS: SSL connect attempt failed with unknown
error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
Expected results:
Should get a successful connection
Additional info:
In my script, where I am using perl-Mail-IMAPClient as a consumer of
perl-IO-Socket-SSL in order to avoid the nasty error above I have to include
SL_ca_file => '/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'
Given that that is just pointing at the existing global default certificate
store, I really ought not need to do this.
While I am at it, I would also argue that SSL_verify_mode => SSL_VERIFY_PEER be
default forcing one to set it otherwise if one wants to ignore certificate
verification such as one has to do with other tools like curl's -k argument,
etc.
--- Additional comment from Petr Pisar on 2016-12-08 02:45:19 EST ---
You complain about this warning you get if you do not set the values
explicitly:
*******************************************************************
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
together with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
This is a documented feature of IO-Socket-SSL-1.94 that was the latest current
when Red Hat Enterprise Linux version 7 was created.
If you request changing the default behavior, please contact Red Hat support to
help you with evaluating and escalating your issue properly.
--- Additional comment from Brian J. Murrell on 2016-12-08 05:55:52 EST ---
I'm not saying that it's not the default behaviour upstream. What I am saying
is that Red Hat's engineering and market focus means that it can do better than
what is upstream.
Upstream have no idea where the certificate store is for a given installation
or who their users are.
Red Hat does, on both counts. Red Hat's engineering provide systems with a
central/global certificate store and Red Hat knows it has enterprise users who
are interested in security. Both of those, IMHO, mean that Red Hat can adjust
this default behaviour to provide an overall better integrated experience.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 3 months