Bug 2113888 - PHP 8 snmp3 Calls Using authPriv or authNoPriv Immediately Return False Without Error Message
Summary: PHP 8 snmp3 Calls Using authPriv or authNoPriv Immediately Return False Witho...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 35
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 2104630
Blocks: 2112814
TreeView+ depends on / blocked
 
Reported: 2022-08-02 09:50 UTC by Remi Collet
Modified: 2022-08-12 01:41 UTC (History)
7 users (show)

Fixed In Version: php-8.0.22-1.fc35
Doc Type: ---
Doc Text:
Clone Of: 2104630
Environment:
Last Closed: 2022-08-12 01:41:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Remi Collet 2022-08-02 09:50:43 UTC
+++ This bug was initially created as a clone of Bug #2104630 +++

Description of problem:

snmp3 function calls in PHP 8 under CentOS 9 Stream x86_64 using the snmp3 options "authPriv" or "authNoPriv" immediately return "false" without any error message and without sending any traffic to destination host. This is true whether the auth protocol is "SHA" or "MD5". This problem does not occur for "noAuthNoPriv" PHP 8 snmp3 function calls against the same target host, nor from the same server using the standalone snmpwalk utility with "authPriv" or "authNoPriv" snmp3 options against the same target host, so it seems to potentially be related to the PHP 8 snmp3 crypto integration.

example calls with the immediate return of "false" with no error message:

snmp3_get([host], [user], 'authPriv', 'SHA', '[auth_pw]', 'AES', '[priv_pw]', [mib])

snmp3_walk([host], [user], 'authPriv', 'SHA', [auth_pw], 'AES', [priv_pw]', [mib]));

snmp3_real_walk([host], [user], 'authPriv', 'SHA', [auth_pw], 'AES', [priv_pw], [mib]);


Version-Release number of selected component (if applicable):

CentOS Version: 9 Stream
uname: Linux [hostname] 5.14.0-101.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 27 10:28:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
php: php-8.0.13-1.el9.x86_64
php-snmp: php-snmp-8.0.13-1.el9.x86_64
openssl: openssl-3.0.1-18.el9.x86_64
net-snmp: net-snmp-5.9.1-7.el9.x86_64
net-snmp-libs: net-snmp-libs-5.9.1-7.el9.x86_64

How reproducible:


Steps to Reproduce:

1. Install CentOS Stream 9 x86_64

2. Install PHP and PHP-SNMP plus any supporting PHP and SNMP packages to same versions as listed in "Version-Release" section

3. Ensure any dependent crypto libraries are installed

4. Ensure PHP error display is enabled and will show all errors

5. Make calls to snmp3 PHP functions such as snmp3_get, snmp3_walk, or snmp3_real_walk with the "authPriv" or "authNoPriv" options and a valid list of values replacing the field tokens from the function calls in the "Description of problem" section. Assign the return value to a variable and dump variable value to confirm it is "false". Record network traffic to confirm that no traffic is sent to target host prior to "false" return with no error message.

Actual results:

When all function fields are valid and the function should otherwise work as it did in PHP 7, snmp3 calls as detailed in "Description of problem" immediately return "false" and do not provide any error message, but only in the case where "authPriv" or "authNoPriv" is specified and auth will be used. No traffic is sent to SNMP target host prior to "false" return.


Expected results:

When there are no syntax or other issues with the snmp3 function calls, the calls should at least send traffic to the target host to begin the snmp3 polling process. If no error, then an array of return results should be provided. If a legitimate error is encountered then an error message should be provided.


Additional info:

  The same calls work fine on a Ubuntu server 22.04 x86_64 set-up running PHP 8.1.2-1 and the following packages:

php-snmp/jammy,now 2:8.1+92ubuntu1 all
php/jammy,now 2:8.1+92ubuntu1 all
php8.1-snmp/jammy-updates,jammy-security,now 8.1.2-1ubuntu2.1 amd64
openssl/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 amd64
libsnmp-base/jammy-updates,now 5.9.1+dfsg-1ubuntu2.1 all
libsnmp40/jammy-updates,now 5.9.1+dfsg-1ubuntu2.1 amd64

  Anecdotally, this same issue was seen within the Red Hat family after performing an inline upgrade from Fedora 34 x86_64 (PHP 7) where PHP snmp3 function calls were working, to Fedora 35 x86_64 (PHP 8).

--- Additional comment from Remi Collet on 2022-07-28 14:27:13 UTC ---

sha1 is deprecated and disabled in 9

Please try SHA256 or SHA512
Or try to lower security policy to LEGACY (using update-crypto-policies)

--- Additional comment from ISV-PA on 2022-07-28 21:04:22 UTC ---

Thank you for the response Remi.

A downgrade to PHP 7.4 on the same CentOS 9 Stream server using the remi repo results in the same problematic PHP SNMP3 calls now working properly. This would presumably rule out it being an issue with SHA support or needing legacy crypto policies in CentOS 9. With other factors aside from PHP version being the same, the calls do not work under Centos 9's PHP 8.x packages, but do work under legacy PHP 7.4.

--- Additional comment from ISV-PA on 2022-07-28 21:18:58 UTC ---

Regarding the suggestion to use SHA256 or SHA512, I should have included in my last update comment that the php.net documentation for the PHP functions such as "snmp3_get" mention only two possibilities for "auth_protocol" --

snmp3_get(
    string $hostname,
    string $security_name,
    string $security_level,
    string $auth_protocol,
    string $auth_passphrase,
    string $privacy_protocol,
    string $privacy_passphrase,
    array|string $object_id,
    int $timeout = -1,
    int $retries = -1
): mixed

auth_protocol
 the authentication protocol (MD5 or SHA)

  i.e. only "MD5" and "SHA" seem to be valid options, with no mention of higher security SHA options such as SHA256 or SHA512.

--- Additional comment from Remi Collet on 2022-07-29 05:31:13 UTC ---

(In reply to ISV-PA from comment #3)
>   i.e. only "MD5" and "SHA" seem to be valid options, with no mention of
> higher security SHA options such as SHA256 or SHA512.

Documentation issue ;)
=> https://github.com/php/doc-en/pull/1727

--- Additional comment from Remi Collet on 2022-07-29 07:22:33 UTC ---

I was able to reproduce on Fedora

$ php82 -r 'var_dump(snmp3_get("localhost", "adminSHA",  "authNoPriv", "SHA", "test1234", "", "", ".1.3.6.1.2.1.1.1.0"));'
string(117) "STRING: Linux builder.remirepo.net 5.18.13-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:20:24 UTC 2022 x86_64"

$ php81 -r 'var_dump(snmp3_get("localhost", "adminSHA",  "authNoPriv", "SHA", "test1234", "", "", ".1.3.6.1.2.1.1.1.0"));'
string(117) "STRING: Linux builder.remirepo.net 5.18.13-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:20:24 UTC 2022 x86_64"

$ php80 -r 'var_dump(snmp3_get("localhost", "adminSHA",  "authNoPriv", "SHA", "test1234", "", "", ".1.3.6.1.2.1.1.1.0"));'
bool(false)

$ php74 -r 'var_dump(snmp3_get("localhost", "adminSHA",  "authNoPriv", "SHA", "test1234", "", "", ".1.3.6.1.2.1.1.1.0"));'
string(117) "STRING: Linux builder.remirepo.net 5.18.13-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:20:24 UTC 2022 x86_64"


This is related to backport in our PHP 8.0 build

With the proper fix

$ php80 -r 'var_dump(snmp3_get("localhost", "adminSHA",  "authNoPriv", "SHA", "test1234", "", "", ".1.3.6.1.2.1.1.1.0"));'
string(117) "STRING: Linux builder.remirepo.net 5.18.13-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:20:24 UTC 2022 x86_64"

--- Additional comment from Remi Collet on 2022-07-29 07:39:54 UTC ---

Fixed in Fedora 35 (will be included next week in upcoming 8.0.22)
https://src.fedoraproject.org/rpms/php/c/217cba0df6d5f2bcce1cd16b66c6ef24e25b6cc1?branch=f35

Comment 1 Fedora Update System 2022-08-02 09:51:18 UTC
FEDORA-2022-0e347699ef has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-0e347699ef

Comment 2 Fedora Update System 2022-08-03 02:56:47 UTC
FEDORA-2022-0e347699ef has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-0e347699ef`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0e347699ef

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 3 Fedora Update System 2022-08-12 01:41:27 UTC
FEDORA-2022-0e347699ef has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.