[Sts-sponsors] [Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
** Changed in: openssl (Ubuntu) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. As a non-empty reply is incorrect behavior To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1939853] Re: mysqli: Using a cursor with get_result() and prepared statements causes a segmentation fault
uploaded to b/f queues, thanks!
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1939853
Title:
mysqli: Using a cursor with get_result() and prepared statements
causes a segmentation fault
Status in php7.2 package in Ubuntu:
Fix Released
Status in php7.4 package in Ubuntu:
Fix Released
Status in php7.2 source package in Bionic:
In Progress
Status in php7.4 source package in Focal:
In Progress
Bug description:
[Impact]
If you attempt to use a prepared statement with the mysqli database
driver to create a cursor which you then execute() and fetch rows with
get_result() and then fetch_assoc(), php with hit a segmentation fault
on every query and terminate.
This is because cursors aren't actually implemented for prepared
statements for the mysqli driver in php 7.2 and 7.4, the versions in
Bionic and Focal. When we try and use a cursor, we just segfault on a
type mismatch when the cursor calls fetch_row().
The fix comes in two forms. The first commit fixes the segfault and
makes php return an error to the user, and the second commit
implements support for cursors on prepared statements. When combined,
these commits fix the issue.
A workaround is to not use prepared statements, and instead use
query() directly.
[Test case]
Install PHP and mysql-client:
Focal:
$ sudo apt install php7.4 php7.4-mysql mysql-client
Bionic:
$ sudo apt install php7.2 php7.2-mysql mysql-client
Next, install and configure mysql 5.3:
$ sudo apt install libncurses5 libaio1 libmecab2
$ wget
https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz
$ groupadd mysql
$ useradd -r -g mysql -s /bin/false mysql
$ cd /usr/local
$ tar zxvf /home/ubuntu/mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz
$ ln -s mysql-5.7.35-linux-glibc2.12-x86_64 mysql
$ cd mysql
$ mkdir mysql-files
$ chown mysql:mysql mysql-files
$ chmod 750 mysql-files
$ bin/mysqld --initialize --user=mysql
$ bin/mysql_ssl_rsa_setup
$ bin/mysqld_safe --user=mysql &
# [Note] A temporary password is generated for root@localhost:
*rjfy#_w(8kM
Access the DBMS and add users, databases and tables, along with some
data:
$ mysql -h 127.0.0.1 -P 3306 -u root -p
ALTER USER 'root'@'localhost' IDENTIFIED BY 'ubuntu';
CREATE DATABASE ubuntu_releases;
use ubuntu_releases;
CREATE TABLE ubuntu_releases (year INT, month INT, name VARCHAR(20)) ;
INSERT INTO ubuntu_releases VALUES (21, 04, 'hirsute');
INSERT INTO ubuntu_releases VALUES (20, 10, 'groovy');
INSERT INTO ubuntu_releases VALUES (20, 04, 'focal');
CREATE USER 'ubuntu' IDENTIFIED BY 'ubuntu';
GRANT ALL PRIVILEGES ON ubuntu_releases.* TO 'ubuntu';
exit
Save the following script to testcase.php:
prepare($SQL);
$stmt->attr_set(MYSQLI_STMT_ATTR_CURSOR_TYPE, MYSQLI_CURSOR_TYPE_READ_ONLY);
$stmt->execute();
if ($stmt) {
$res = $stmt->get_result();
while($row = $res->fetch_assoc()) {
echo json_encode($row) . "\n";
}
}
$dbConn->close()
?>
Run the php script:
$ php testcase.php
Segmentation fault (core dumped)
A ppa with test packages is available below:
https://launchpad.net/~mruffell/+archive/ubuntu/sf315485-test
When you install the test packages, you should see:
$ php testcase.php
{"year":21,"month":4,"name":"hirsute"}
{"year":20,"month":10,"name":"groovy"}
{"year":20,"month":4,"name":"focal"}
[Where problems can occur]
We are changing the behaviour of how cursors work in the mysqli
database driver backend. Luckily, we are only changing how they work
for prepared statements in mysqli, and it doesn't affect any other
database driver backend, or regular queries with mysqli.
Since attempting to use a cursor with prepared statements on mysqli
backend results in a segfault due to it not being implemented, there
won't be any users that are using cursors with prepared statements,
since their applications would crash. Adding support likely won't
break any existing users, as attempting to use such features before
would result in a hard crash, versus making existing code start
working or behave differently.
There is still risk these changes could introduce a regression, and it
would be restricted to users using the mysqli database driver, which I
imagine are a significant amount of the userbase, due to the
popularity of mysql and mariadb. If a regression were to occur, users
might need to change their database driver interface code, or in worst
case, change to direct queries from prepared statements while a fix is
created.
[Other Info]
The following commit fixes the segmentation fault and changes it to an
not implemented error:
commit b5481defe64c991d0e4307372d69c0ea3cd83378
Author: Dharman
Date: Thu Sep 17 12:35:26 2020 +0100
Subject: Fix bug #72413: Segfault with
[Sts-sponsors] [Bug 1939853] Re: mysqli: Using a cursor with get_result() and prepared statements causes a segmentation fault
** Tags added: sts-sponsor-ddstreet
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1939853
Title:
mysqli: Using a cursor with get_result() and prepared statements
causes a segmentation fault
Status in php7.2 package in Ubuntu:
Fix Released
Status in php7.4 package in Ubuntu:
Fix Released
Status in php7.2 source package in Bionic:
In Progress
Status in php7.4 source package in Focal:
In Progress
Bug description:
[Impact]
If you attempt to use a prepared statement with the mysqli database
driver to create a cursor which you then execute() and fetch rows with
get_result() and then fetch_assoc(), php with hit a segmentation fault
on every query and terminate.
This is because cursors aren't actually implemented for prepared
statements for the mysqli driver in php 7.2 and 7.4, the versions in
Bionic and Focal. When we try and use a cursor, we just segfault on a
type mismatch when the cursor calls fetch_row().
The fix comes in two forms. The first commit fixes the segfault and
makes php return an error to the user, and the second commit
implements support for cursors on prepared statements. When combined,
these commits fix the issue.
A workaround is to not use prepared statements, and instead use
query() directly.
[Test case]
Install PHP and mysql-client:
Focal:
$ sudo apt install php7.4 php7.4-mysql mysql-client
Bionic:
$ sudo apt install php7.2 php7.2-mysql mysql-client
Next, install and configure mysql 5.3:
$ sudo apt install libncurses5 libaio1 libmecab2
$ wget
https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz
$ groupadd mysql
$ useradd -r -g mysql -s /bin/false mysql
$ cd /usr/local
$ tar zxvf /home/ubuntu/mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz
$ ln -s mysql-5.7.35-linux-glibc2.12-x86_64 mysql
$ cd mysql
$ mkdir mysql-files
$ chown mysql:mysql mysql-files
$ chmod 750 mysql-files
$ bin/mysqld --initialize --user=mysql
$ bin/mysql_ssl_rsa_setup
$ bin/mysqld_safe --user=mysql &
# [Note] A temporary password is generated for root@localhost:
*rjfy#_w(8kM
Access the DBMS and add users, databases and tables, along with some
data:
$ mysql -h 127.0.0.1 -P 3306 -u root -p
ALTER USER 'root'@'localhost' IDENTIFIED BY 'ubuntu';
CREATE DATABASE ubuntu_releases;
use ubuntu_releases;
CREATE TABLE ubuntu_releases (year INT, month INT, name VARCHAR(20)) ;
INSERT INTO ubuntu_releases VALUES (21, 04, 'hirsute');
INSERT INTO ubuntu_releases VALUES (20, 10, 'groovy');
INSERT INTO ubuntu_releases VALUES (20, 04, 'focal');
CREATE USER 'ubuntu' IDENTIFIED BY 'ubuntu';
GRANT ALL PRIVILEGES ON ubuntu_releases.* TO 'ubuntu';
exit
Save the following script to testcase.php:
prepare($SQL);
$stmt->attr_set(MYSQLI_STMT_ATTR_CURSOR_TYPE, MYSQLI_CURSOR_TYPE_READ_ONLY);
$stmt->execute();
if ($stmt) {
$res = $stmt->get_result();
while($row = $res->fetch_assoc()) {
echo json_encode($row) . "\n";
}
}
$dbConn->close()
?>
Run the php script:
$ php testcase.php
Segmentation fault (core dumped)
A ppa with test packages is available below:
https://launchpad.net/~mruffell/+archive/ubuntu/sf315485-test
When you install the test packages, you should see:
$ php testcase.php
{"year":21,"month":4,"name":"hirsute"}
{"year":20,"month":10,"name":"groovy"}
{"year":20,"month":4,"name":"focal"}
[Where problems can occur]
We are changing the behaviour of how cursors work in the mysqli
database driver backend. Luckily, we are only changing how they work
for prepared statements in mysqli, and it doesn't affect any other
database driver backend, or regular queries with mysqli.
Since attempting to use a cursor with prepared statements on mysqli
backend results in a segfault due to it not being implemented, there
won't be any users that are using cursors with prepared statements,
since their applications would crash. Adding support likely won't
break any existing users, as attempting to use such features before
would result in a hard crash, versus making existing code start
working or behave differently.
There is still risk these changes could introduce a regression, and it
would be restricted to users using the mysqli database driver, which I
imagine are a significant amount of the userbase, due to the
popularity of mysql and mariadb. If a regression were to occur, users
might need to change their database driver interface code, or in worst
case, change to direct queries from prepared statements while a fix is
created.
[Other Info]
The following commit fixes the segmentation fault and changes it to an
not implemented error:
commit b5481defe64c991d0e4307372d69c0ea3cd83378
Author: Dharman
Date: Thu Sep 17 12:35:26 2020 +0100
Subject: Fix bug #72413: Segfault with
[Sts-sponsors] [Bug 1914584] [NEW] [SRU] radosgw-admin user create error message confusing if user with email already exists
You have been subscribed to a public bug by Victor Tapia (vtapia): [Impact] When creating a new S3 user, the error message is confusing if the email address used is already associated with another S3 account. To reproduce: radosgw-admin user create --uid=foo --display-name="Foo test" --email=bar@domain.invalid #[ success ] radosgw-admin user create --uid=test --display-name="AN test" --email=bar@domain.invalid could not create user: unable to parse parameters, user id mismatch, operation id: foo does not match: test As a result, it's completely unclear what went wrong with the user creation. [Test case] Create an S3 account via radosgw-admin. Then create another user but use the same email address - it should provide a clear description of what the problem is. [Where problems could occur] The new message may yet be unclear or could complain that an email exists even though it doesn't exist (false positive). It's an improved diagnostic by checking if the email id exists. Perhaps, user creation might become problematic if the fix doesn't work. [Other Info] - The patch was provided by Matthew Vernon (attached here) - Upstream tracker: https://tracker.ceph.com/issues/49137 - Upstream PR: https://github.com/ceph/ceph/pull/39293 - Backported to Pacific, Octopus, and Nautilus upstream releases. Luminous is EOL'ed upstream, so we'd like to backport to Luminous (Bionic/queens). ** Affects: ceph Importance: Unknown Status: Unknown ** Affects: cloud-archive Importance: Low Status: New ** Affects: cloud-archive/queens Importance: Low Status: Won't Fix ** Affects: cloud-archive/rocky Importance: Low Status: Won't Fix ** Affects: cloud-archive/stein Importance: Low Status: Won't Fix ** Affects: cloud-archive/train Importance: Low Status: Won't Fix ** Affects: cloud-archive/ussuri Importance: Low Status: New ** Affects: cloud-archive/victoria Importance: Low Status: New ** Affects: ceph (Ubuntu) Importance: Low Status: New ** Affects: ceph (Ubuntu Bionic) Importance: Low Status: New ** Affects: ceph (Ubuntu Focal) Importance: Low Status: New ** Affects: ceph (Ubuntu Groovy) Importance: Low Status: New ** Affects: ceph (Ubuntu Hirsute) Importance: Low Status: New ** Tags: amd64 apport-bug bionic patch sts-sru-needed verification-failed verification-failed-focal verification-failed-groovy verification-ussuri-failed -- [SRU] radosgw-admin user create error message confusing if user with email already exists https://bugs.launchpad.net/bugs/1914584 You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
