[uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Dear lists, today we released an unscheduled maintenance update for CVE-2020-8028 (bsc#1175884), which is a security vulnerability of SUSE Manager and Uyuni Servers. The bug has been kept under embargo since it was reported to this day while we prepared a fix and coordinated the release. Only users that have shell access to the Uyuni server can exploit this vulnerability. This is not a common setup, shell access to the server should usually be restricted to the server administrators. In order to install this update please make sure you are on the most recent release (2020.07) and use the following commands on the Uyuni server: zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:... zypper refresh spacewalk-service stop zypper update spacewalk-java-lib spacewalk-java spacewalk-java-config spacewalk-java-postgresql spacewalk-taskomatic spacewalk-admin spacewalk-setup salt-netapi-client spacewalk-service start After services start again, the Salt API endpoint will be authenticated and encrypted. As the fix changes the way the Salt API endpoint is served, it is expected to break any third-party scripts or software that may rely on it. We will take this occasion to remind you that: - the Salt API endpoint configured by Uyuni at installation time is exclusively for internal Uyuni use and by default not exposed to the network. If your custom software depends on using the Salt API directly, you are relying on something not supported by Uyuni. - it is possible to define additional API endpoints, and secure them in a variety of ways, and those are fine for custom scripts. More information about how to configure those are available at: https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_tornado... If applying the update is not readily feasible, we recommend to restrict shell access to the Uyuni Server to the minimum set of users who really need it - which is a standard, recommended security practice in any case. More information is available at: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8028 - https://github.com/uyuni-project/uyuni/pull/2613 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Hi, After updated those packages now some services not starting . ● taskomatic.service - Taskomatic Loaded: loaded (/usr/lib/systemd/system/taskomatic.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/taskomatic.service.d └─override.conf Active: failed (Result: exit-code) since Fri 2020-09-18 09:50:08 EEST; 47min ago Process: 8439 ExecStart=/usr/sbin/taskomatic (code=exited, status=255) Main PID: 8439 (code=exited, status=255) ● spacewalk-wait-for-taskomatic.service - Spacewalk wait for taskomatic Loaded: loaded (/usr/lib/systemd/system/spacewalk-wait-for-taskomatic.service; static; vendor preset: disabled) Active: active (exited) since Fri 2020-09-18 09:51:31 EEST; 46min ago Process: 7290 ExecStart=/usr/sbin/spacewalk-startup-helper wait-for-taskomatic (code=exited, status=0/SUCCESS) Main PID: 7290 (code=exited, status=0/SUCCESS) Tasks: 0 CGroup: /system.slice/spacewalk-wait-for-taskomatic.service ● salt-secrets-config.service - Configures secrets between salt-master and other services Loaded: loaded (/usr/lib/systemd/system/salt-secrets-config.service; static; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/salt-secrets-config.service.d └─override.conf Active: active (exited) since Fri 2020-09-18 09:49:32 EEST; 48min ago Process: 6781 ExecStart=/usr/bin/salt-secrets-config.py (code=exited, status=0/SUCCESS) Main PID: 6781 (code=exited, status=0/SUCCESS) Tasks: 0 CGroup: /system.slice/salt-secrets-config.service ● mgr-websockify.service - TCP to WebSocket proxy Loaded: loaded (/usr/lib/systemd/system/mgr-websockify.service; static; vendor preset: disabled) Active: active (running) since Fri 2020-09-18 09:49:41 EEST; 47min ago Process: 6812 ExecStartPre=/usr/bin/sh -c grep secret_key /etc/rhn/rhn.conf | tr -d ' ' | cut -f2 -d '=' | perl -ne 's/([0-9a-f]{2})/print chr hex $1/gie' > /etc/rhn/websockify.key (code=exited, status=0/SUCCESS) Main PID: 6832 (websockify) Tasks: 4 CGroup: /system.slice/mgr-websockify.service └─6832 /usr/bin/python3 /usr/bin/websockify --token-plugin JWTTokenApi --token-source /etc/rhn/websockify.ke…50 ● spacewalk.target - Spacewalk Loaded: loaded (/usr/lib/systemd/system/spacewalk.target; enabled; vendor preset: disabled) Active: inactive (dead) ● jabberd.service - Jabber Server Loaded: loaded (/usr/lib/systemd/system/jabberd.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago Main PID: 3398 (code=exited, status=0/SUCCESS) ● osa-dispatcher.service - OSA Dispatcher daemon Loaded: loaded (/usr/lib/systemd/system/osa-dispatcher.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago Main PID: 3466 (code=killed, signal=TERM) spacewalk:/var/log # Best Regards, Suhail Siddiqui Service Delivery – Datacenter Services HCL Technologies Ltd. – UPM Partner for IT Services Mob: +91-9717193941 -----Original Message----- From: Julio González Gil <jgonzalez@suse.com> Sent: 16 September 2020 20:15 To: uyuni-announce@opensuse.org; uyuni-devel@opensuse.org; uyuni-users@opensuse.org Subject: [uyuni-announce] Special update for CVE-2020-8028 (bsc#1175884) Dear lists, today we released an unscheduled maintenance update for CVE-2020-8028 (bsc#1175884), which is a security vulnerability of SUSE Manager and Uyuni Servers. The bug has been kept under embargo since it was reported to this day while we prepared a fix and coordinated the release. Only users that have shell access to the Uyuni server can exploit this vulnerability. This is not a common setup, shell access to the server should usually be restricted to the server administrators. In order to install this update please make sure you are on the most recent release (2020.07) and use the following commands on the Uyuni server: zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:... zypper refresh spacewalk-service stop zypper update spacewalk-java-lib spacewalk-java spacewalk-java-config spacewalk-java-postgresql spacewalk-taskomatic spacewalk-admin spacewalk-setup salt-netapi-client spacewalk-service start After services start again, the Salt API endpoint will be authenticated and encrypted. As the fix changes the way the Salt API endpoint is served, it is expected to break any third-party scripts or software that may rely on it. We will take this occasion to remind you that: - the Salt API endpoint configured by Uyuni at installation time is exclusively for internal Uyuni use and by default not exposed to the network. If your custom software depends on using the Salt API directly, you are relying on something not supported by Uyuni. - it is possible to define additional API endpoints, and secure them in a variety of ways, and those are fine for custom scripts. More information about how to configure those are available at: https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_tornado... If applying the update is not readily feasible, we recommend to restrict shell access to the Uyuni Server to the minimum set of users who really need it - which is a standard, recommended security practice in any case. More information is available at: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8028 - https://github.com/uyuni-project/uyuni/pull/2613 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com<mailto:jgonzalez@suse.com> ________________________________ Please note. The information contained in this message is confidential and is intended only for the use of the individual named above and others who have been specially authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. The attachments have been scanned for viruses prior to leaving our E-mail system. UPM-Kymmene Corporation shall not be liable for any consequences of any virus being passed on.
On 18/09/2020 09.38, Suhail Siddiqui, HCL wrote:
Hi,
After updated those packages now some services not starting .
[...]
● spacewalk-wait-for-taskomatic.service - Spacewalk wait for taskomatic Loaded: loaded (/usr/lib/systemd/system/spacewalk-wait-for-taskomatic.service; static; vendor preset: disabled) Active: active (exited) since Fri 2020-09-18 09:51:31 EEST; 46min ago Process: 7290 ExecStart=/usr/sbin/spacewalk-startup-helper wait-for-taskomatic (code=exited, status=0/SUCCESS) Main PID: 7290 (code=exited, status=0/SUCCESS)
OK so this is expected and not really a problem.
● spacewalk.target - Spacewalk Loaded: loaded (/usr/lib/systemd/system/spacewalk.target; enabled; vendor preset: disabled) Active: inactive (dead)
This is a target, so it fails because some other unit has failed.
● jabberd.service - Jabber Server Loaded: loaded (/usr/lib/systemd/system/jabberd.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago Main PID: 3398 (code=exited, status=0/SUCCESS)
● osa-dispatcher.service - OSA Dispatcher daemon
Loaded: loaded (/usr/lib/systemd/system/osa-dispatcher.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago
Main PID: 3466 (code=killed, signal=TERM)
Here we have a problem I would say. First of all please try restarting those services, and report the output of `systemctl status <SERVICE>` again. More clues might be found in `journalctl -u <SERVICE>` or log files, specifically /var/log/rhn/osa-dispatcher.log. Do you notice anything strange in there? Regards, -- Silvio Moioli SUSE Manager Development Team -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
Hi, I updated according the instructions, but the server does not start again. spacewalk-service status <rest is green> �� taskomatic.service - Taskomatic Loaded: loaded (/usr/lib/systemd/system/taskomatic.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/taskomatic.service.d ����override.conf Active: failed (Result: exit-code) since Tue 2020-09-22 12:00:15 CEST; 13min ago Process: 18028 ExecStart=/usr/sbin/taskomatic (code=exited, status=255) Main PID: 18028 (code=exited, status=255) <rest is green> journalctl -u tomcat.service Sep 22 11:57:06 smduyuni server[15493]: 22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file Sep 22 11:57:06 smduyuni server[15493]: 22-Sep-2020 11:57:06.977 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal Context [/rhn] startup failed due to previous errors localhost.2020-09-22.log 22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [com.redhat.rhn.webapp.RhnServletListener] java.lang.NoSuchFieldError: FILE at com.suse.manager.webui.services.impl.SaltService.<init>(SaltService.java:151) at com.suse.manager.webui.services.impl.SaltService.<clinit>(SaltService.java:136) at com.redhat.rhn.webapp.RhnServletListener.<init>(RhnServletListener.java:56) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4602) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5139) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1133) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1866) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1045) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) 22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Skipped installing application listeners due to previous error(s) Regards, Torsten
-----Original Message----- From: Julio Gonz��lez Gil [mailto:jgonzalez@suse.com] Sent: Wednesday, September 16, 2020 7:15 PM To: uyuni-announce@opensuse.org; uyuni-devel@opensuse.org; uyuni- users@opensuse.org Subject: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Dear lists,
today we released an unscheduled maintenance update for CVE-2020-8028 (bsc#1175884), which is a security vulnerability of SUSE Manager and Uyuni Servers. The bug has been kept under embargo since it was reported to this day while we prepared a fix and coordinated the release.
Only users that have shell access to the Uyuni server can exploit this vulnerability. This is not a common setup, shell access to the server should usually be restricted to the server administrators.
In order to install this update please make sure you are on the most recent release (2020.07) and use the following commands on the Uyuni server:
zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stab le:/Patches/openSUSE_Leap_15.2/systemsmanagement:Uyuni:Stable:Patches.r epo zypper refresh spacewalk-service stop zypper update spacewalk-java-lib spacewalk-java spacewalk-java-config spacewalk-java-postgresql spacewalk-taskomatic spacewalk-admin spacewalk- setup salt-netapi-client spacewalk-service start
After services start again, the Salt API endpoint will be authenticated and encrypted.
As the fix changes the way the Salt API endpoint is served, it is expected to break any third-party scripts or software that may rely on it. We will take this occasion to remind you that:
- the Salt API endpoint configured by Uyuni at installation time is exclusively for internal Uyuni use and by default not exposed to the network. If your custom software depends on using the Salt API directly, you are relying on something not supported by Uyuni. - it is possible to define additional API endpoints, and secure them in a variety of ways, and those are fine for custom scripts. More information about how to configure those are available at: https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_tornado... ml#module-salt.netapi.rest_tornado
If applying the update is not readily feasible, we recommend to restrict shell access to the Uyuni Server to the minimum set of users who really need it - which is a standard, recommended security practice in any case.
More information is available at: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8028 - https://github.com/uyuni-project/uyuni/pull/2613
-- Julio Gonz��lez Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com N�����r��y隊[��x������칻 �&ޢ���� ����'��-���w�zf��쮞+�z�>� ޮ�^�ˬz��
On 22/09/2020 12.21, Haupt, Torsten wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [com.redhat.rhn.webapp.RhnServletListener] java.lang.NoSuchFieldError: FILE at com.suse.manager.webui.services.impl.SaltService.<init>(SaltService.java:151)
Can you please double check and report here the versions of the following packages: spacewalk-java-lib and salt-netapi-client please? Regards, -- Silvio Moioli SUSE Manager Development Team -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
Now that I see Silvio's message, I think I know where the problem is. https://build.opensuse.org/package/binaries/systemsmanagement:Uyuni:Stable/ salt-netapi-client/openSUSE_Leap_15.2 (stable version) and https://build.opensuse.org/package/binaries/ systemsmanagement:Uyuni:Stable:Patches/salt-netapi-client/openSUSE_Leap_15.2 (patches) Have exactly the same version and release, as they were built only once at both projects. Next time we *really* need to bump the version of all packages part of a patch. For now, can you try the following as root?
spacewalk-service status stop wget https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/ Stable:/Patches/openSUSE_Leap_15.2/noarch/salt-netapi- client-0.17.0-1.1.uyuni.noarch.rpm rpm -i --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm spacewalk-service status start
If it works, I will publish this as the fix until Uyuni 2020.09 is out (today/ tomorrow). This should On martes, 22 de septiembre de 2020 12:27:19 (CEST) Silvio Moioli wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [com.redhat.rhn.webapp.RhnServletListener]> java.lang.NoSuchFieldError: FILE
at com.suse.manager.webui.services.impl.SaltService.<init>(S altService.java:151) Can you please double check and report here the versions of the following
On 22/09/2020 12.21, Haupt, Torsten wrote: packages: spacewalk-java-lib and salt-netapi-client please?
Regards, -- Silvio Moioli SUSE Manager Development Team
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Yes, Uyuni starts again. But I needed a "--force" in the rpm command. Thanks Torsten
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 12:47 PM To: uyuni-users@opensuse.org Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Now that I see Silvio's message, I think I know where the problem is.
https://build.opensuse.org/package/binaries/systemsmanagement:Uyuni:Stable / salt-netapi-client/openSUSE_Leap_15.2 (stable version) and https://build.opensuse.org/package/binaries/ systemsmanagement:Uyuni:Stable:Patches/salt-netapi- client/openSUSE_Leap_15.2 (patches)
Have exactly the same version and release, as they were built only once at both projects. Next time we *really* need to bump the version of all packages part of a patch.
For now, can you try the following as root?
spacewalk-service status stop wget https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/ Stable:/Patches/openSUSE_Leap_15.2/noarch/salt-netapi- client-0.17.0-1.1.uyuni.noarch.rpm rpm -i --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm spacewalk-service status start
If it works, I will publish this as the fix until Uyuni 2020.09 is out (today/ tomorrow).
This should On martes, 22 de septiembre de 2020 12:27:19 (CEST) Silvio Moioli wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [com.redhat.rhn.webapp.RhnServletListener]> java.lang.NoSuchFieldError: FILE
at com.suse.manager.webui.services.impl.SaltService.<init>(S altService.java:151) Can you please double check and report here the versions of the following
On 22/09/2020 12.21, Haupt, Torsten wrote: packages: spacewalk-java-lib and salt-netapi-client please?
Regards, -- Silvio Moioli SUSE Manager Development Team
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
On martes, 22 de septiembre de 2020 13:20:40 (CEST) Haupt, Torsten wrote:
Yes, Uyuni starts again. But I needed a "--force" in the rpm command. Thanks
Only a "--force", or did you need both "--force" and "--replacepkgs" at the same time?
Torsten
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 12:47 PM To: uyuni-users@opensuse.org Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Now that I see Silvio's message, I think I know where the problem is.
https://build.opensuse.org/package/binaries/systemsmanagement:Uyuni:Stable / salt-netapi-client/openSUSE_Leap_15.2 (stable version) and https://build.opensuse.org/package/binaries/ systemsmanagement:Uyuni:Stable:Patches/salt-netapi- client/openSUSE_Leap_15.2 (patches)
Have exactly the same version and release, as they were built only once at both projects. Next time we *really* need to bump the version of all packages part of a patch.
For now, can you try the following as root?
spacewalk-service status stop wget https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/
Stable:/Patches/openSUSE_Leap_15.2/noarch/salt-netapi- client-0.17.0-1.1.uyuni.noarch.rpm
rpm -i --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm spacewalk-service status start
If it works, I will publish this as the fix until Uyuni 2020.09 is out (today/ tomorrow).
This should
On martes, 22 de septiembre de 2020 12:27:19 (CEST) Silvio Moioli wrote:
On 22/09/2020 12.21, Haupt, Torsten wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class
[com.redhat.rhn.webapp.RhnServletListener]>
java.lang.NoSuchFieldError: FILE
at com.suse.manager.webui.services.impl.SaltService.<init >(S altService.java:151)
Can you please double check and report here the versions of the following packages: spacewalk-java-lib and salt-netapi-client please?
Regards, -- Silvio Moioli SUSE Manager Development Team
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 2:54 PM To: uyuni-users@opensuse.org; Haupt, Torsten <Torsten.Haupt@lhw.mlu.sachsen-anhalt.de> Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
On martes, 22 de septiembre de 2020 13:20:40 (CEST) Haupt, Torsten wrote:
Yes, Uyuni starts again. But I needed a "--force" in the rpm command. Thanks
Only a "--force", or did you need both "--force" and "--replacepkgs" at the same time?
I have used both options. I have not tried it without "--replacepkgs".
Torsten
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 12:47 PM To: uyuni-users@opensuse.org Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Now that I see Silvio's message, I think I know where the problem is.
https://build.opensuse.org/package/binaries/systemsmanagement:Uyuni: Stable / salt-netapi-client/openSUSE_Leap_15.2 (stable version) and https://build.opensuse.org/package/binaries/ systemsmanagement:Uyuni:Stable:Patches/salt-netapi- client/openSUSE_Leap_15.2 (patches)
Have exactly the same version and release, as they were built only once at both projects. Next time we *really* need to bump the version of all packages part of a patch.
For now, can you try the following as root?
spacewalk-service status stop wget https://download.opensuse.org/repositories/systemsmanagement:/Uyun i:/
Stable:/Patches/openSUSE_Leap_15.2/noarch/salt-netapi- client-0.17.0-1.1.uyuni.noarch.rpm
rpm -i --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm spacewalk-service status start
If it works, I will publish this as the fix until Uyuni 2020.09 is out (today/ tomorrow).
This should
On martes, 22 de septiembre de 2020 12:27:19 (CEST) Silvio Moioli wrote:
On 22/09/2020 12.21, Haupt, Torsten wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class
[com.redhat.rhn.webapp.RhnServletListener]>
java.lang.NoSuchFieldError: FILE
at com.suse.manager.webui.services.impl.SaltService.<init >(S altService.java:151)
Can you please double check and report here the versions of the following packages: spacewalk-java-lib and salt-netapi-client please?
Regards, -- Silvio Moioli SUSE Manager Development Team
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
Thanks for confirming. Will send an announcemene today, for the people applying the patch. Uyuni 2020.09 (release today/tomorrow) will have this fixed. Best regards. On martes, 22 de septiembre de 2020 15:04:33 (CEST) Haupt, Torsten wrote:
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 2:54 PM To: uyuni-users@opensuse.org; Haupt, Torsten <Torsten.Haupt@lhw.mlu.sachsen-anhalt.de> Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
On martes, 22 de septiembre de 2020 13:20:40 (CEST) Haupt, Torsten wrote:
Yes, Uyuni starts again. But I needed a "--force" in the rpm command. Thanks
Only a "--force", or did you need both "--force" and "--replacepkgs" at the same time?
I have used both options. I have not tried it without "--replacepkgs".
Torsten
-----Original Message----- From: Julio González Gil [mailto:jgonzalez@suse.com] Sent: Tuesday, September 22, 2020 12:47 PM To: uyuni-users@opensuse.org Cc: Silvio Moioli <moio@suse.de> Subject: [EXTERN] Re: [EXTERN] [uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
Now that I see Silvio's message, I think I know where the problem is.
https://build.opensuse.org/package/binaries/systemsmanagement:Uyuni: Stable / salt-netapi-client/openSUSE_Leap_15.2 (stable version) and https://build.opensuse.org/package/binaries/ systemsmanagement:Uyuni:Stable:Patches/salt-netapi- client/openSUSE_Leap_15.2 (patches)
Have exactly the same version and release, as they were built only once at both projects. Next time we *really* need to bump the version of all packages part of a patch.
For now, can you try the following as root?
spacewalk-service status stop wget https://download.opensuse.org/repositories/systemsmanagement:/Uyun i:/
Stable:/Patches/openSUSE_Leap_15.2/noarch/salt-netapi- client-0.17.0-1.1.uyuni.noarch.rpm
rpm -i --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm spacewalk-service status start
If it works, I will publish this as the fix until Uyuni 2020.09 is out (today/ tomorrow).
This should
On martes, 22 de septiembre de 2020 12:27:19 (CEST) Silvio Moioli wrote:
On 22/09/2020 12.21, Haupt, Torsten wrote:
22-Sep-2020 11:57:06.953 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class
[com.redhat.rhn.webapp.RhnServletListener]>
java.lang.NoSuchFieldError: FILE
at com.suse.manager.webui.services.impl.SaltService.< init
>(S
altService.java:151)
Can you please double check and report here the versions of the following packages: spacewalk-java-lib and salt-netapi-client please?
Regards, -- Silvio Moioli SUSE Manager Development Team
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Hi, For those that tried to update and got a problem where the services did not restart, please run the following commands as root on the server:
spacewalk-service status stop
wget https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:...
rpm -i --force --replacepkgs salt-netapi-client-0.17.0-1.1.uyuni.noarch.rpm
spacewalk-service status start
The problem happened because the version and the released of the salt-netapi-client package were the same at the Stable reposity and at the Patches repository. The commands above will download the RPM from the Patches repository and will force an installation ignoring the fact that the version installed on the system is the same that is going to be installed. Next time we need to provide such a patch, we will avoid such problem by always providing a new version for all packages (in this case salt-netapi-client got a patch, but not a new version, while all other packages got the source code changed and an new version). Kudos to Torsten Haupt for his help testing the fix for this problem! Best regards. On miércoles, 16 de septiembre de 2020 19:15:22 (CEST) Julio González Gil wrote:
Dear lists,
today we released an unscheduled maintenance update for CVE-2020-8028 (bsc#1175884), which is a security vulnerability of SUSE Manager and Uyuni Servers. The bug has been kept under embargo since it was reported to this day while we prepared a fix and coordinated the release.
Only users that have shell access to the Uyuni server can exploit this vulnerability. This is not a common setup, shell access to the server should usually be restricted to the server administrators.
In order to install this update please make sure you are on the most recent release (2020.07) and use the following commands on the Uyuni server:
zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable :/Patches/openSUSE_Leap_15.2/systemsmanagement:Uyuni:Stable:Patches.repo zypper refresh spacewalk-service stop zypper update spacewalk-java-lib spacewalk-java spacewalk-java-config spacewalk-java-postgresql spacewalk-taskomatic spacewalk-admin spacewalk-setup salt-netapi-client spacewalk-service start
After services start again, the Salt API endpoint will be authenticated and encrypted.
As the fix changes the way the Salt API endpoint is served, it is expected to break any third-party scripts or software that may rely on it. We will take this occasion to remind you that:
- the Salt API endpoint configured by Uyuni at installation time is exclusively for internal Uyuni use and by default not exposed to the network. If your custom software depends on using the Salt API directly, you are relying on something not supported by Uyuni. - it is possible to define additional API endpoints, and secure them in a variety of ways, and those are fine for custom scripts. More information about how to configure those are available at: https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_tornad o.html#module-salt.netapi.rest_tornado
If applying the update is not readily feasible, we recommend to restrict shell access to the Uyuni Server to the minimum set of users who really need it - which is a standard, recommended security practice in any case.
More information is available at: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8028 - https://github.com/uyuni-project/uyuni/pull/2613
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
participants (4)
-
Haupt, Torsten -
Julio González Gil -
Silvio Moioli -
Suhail Siddiqui, HCL