Apache has issued advisories today (January 22): https://www.openwall.com/lists/oss-security/2019/01/22/2 https://www.openwall.com/lists/oss-security/2019/01/22/3 These issues are fixed upstream in 2.4.38: http://www.apache.org/dist/httpd/CHANGES_2.4.38 Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
this should be assigned to shlomif by default.
CC: (none) => mageia
(In reply to Marc Krämer from comment #1) > this should be assigned to shlomif by default. Indeed, he's the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => shlomif
Advisory: ======================== Updated apache packages fix security vulnerabilities: By sending request bodies in a slow loris way to plain resources, the h2 stream for that request unnecessarily occupied a server thread cleaning up that incoming data. This affects only HTTP/2 (mod_http2) connections in Apache HTTP Server versions 2.4.37 and prior (CVE-2018-17189). In Apache HTTP Server 2.4 release 2.4.37 and prior, mod_session checks the session expiry time before decoding the session. This causes session expiry time to be ignored for mod_session_cookie sessions since the expiry time is loaded when the session is decoded (CVE-2018-17199). The apache package has been updated to version 2.4.38, fixing these issues and several other bugs. See the upstream CHANGES files for details. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17189 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17199 http://www.apache.org/dist/httpd/CHANGES_2.4.38 https://httpd.apache.org/security/vulnerabilities_24.html ======================== Updated packages in core/updates_testing: ======================== apache-2.4.38-1.mga6 apache-mod_dav-2.4.38-1.mga6 apache-mod_ldap-2.4.38-1.mga6 apache-mod_session-2.4.38-1.mga6 apache-mod_cache-2.4.38-1.mga6 apache-mod_proxy-2.4.38-1.mga6 apache-mod_proxy_html-2.4.38-1.mga6 apache-mod_suexec-2.4.38-1.mga6 apache-mod_userdir-2.4.38-1.mga6 apache-mod_ssl-2.4.38-1.mga6 apache-mod_dbd-2.4.38-1.mga6 apache-mod_http2-2.4.38-1.mga6 apache-htcacheclean-2.4.38-1.mga6 apache-devel-2.4.38-1.mga6 apache-doc-2.4.38-1.mga6 from apache-2.4.38-1.mga6.src.rpm
Version: Cauldron => 6Assignee: shlomif => qa-bugsWhiteboard: MGA6TOO => (none)
Installed and tested without issue. Tested only a few modules of the available modules so will not mark as OK and wait for more tests. System: Mageia 6, x86_64, Intel CPU. $ uname -a Linux marte 4.14.89-desktop-1.mga6 #1 SMP Mon Dec 17 13:14:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep apache | sort apache-2.4.38-1.mga6 apache-mod_php-7.2.14-1.mga6 apache-mod_ssl-2.4.38-1.mga6
MGA6-32 MATE on IBM Thinkpad R50e No installation issues. This laptop had a working previous version of http, used a.o. to test phpmyadmin. Now at CLI before the update: # systemctl -l status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: enabled) Active: inactive (dead) After the update # systemctl start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. Both status and journal show anything but httpd.service: Unit entered failed state. httpd.service: Failed with result 'exit-code'. Checked /var/log/httpd, log files are empty and # journalctl -b | grep http httpd.service: Main process exited, code=exited, status=1/FAILURE httpd.service: Unit entered failed state. httpd.service: Failed with result 'exit-code'.
CC: (none) => herman.viaene
Removed whol apache bunch, and installed just the apache package alone, and at CLI: # systemctl start httpd # systemctl -l status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled) Active: active (running) since di 2019-02-05 11:04:34 CET; 3s ago Main PID: 20832 (httpd) Status: "Processing requests..." CGroup: /system.slice/httpd.service ├─20832 /usr/sbin/httpd -DFOREGROUND ├─20834 /usr/sbin/httpd -DFOREGROUND ├─20835 /usr/sbin/httpd -DFOREGROUND ├─20836 /usr/sbin/httpd -DFOREGROUND ├─20837 /usr/sbin/httpd -DFOREGROUND └─20838 /usr/sbin/httpd -DFOREGROUND feb 05 11:04:33 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server... feb 05 11:04:34 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server. Seems OK, now # systemctl stop httpd # systemctl -l status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled) Active: inactive (dead) since di 2019-02-05 11:04:57 CET; 3min 57s ago Process: 20832 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=0/SUCCESS) Main PID: 20832 (code=exited, status=0/SUCCESS) Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec" feb 05 11:04:33 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server... feb 05 11:04:34 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server. feb 05 11:04:56 mach6.hviaene.thuis systemd[1]: Stopping The Apache HTTP Server... feb 05 11:04:57 mach6.hviaene.thuis systemd[1]: Stopped The Apache HTTP Server. Looks OK Now install the apache-mod packages and# systemctl start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. I noticed during selecting the packages that one of them draws in nghttp and that is advertized as "experimental http client and server", so I am suspecting this is causing the problem. I'm not sure whether I'll be able to go thru all mod packages individually today. Wait , come back and see.
Removed all apache again and started adding packages one by one at CLI with urpmi, starting with apache: each time checking whether httpd would start properly and stop it again before adding the next one. So apache: OK apache-mod_dav: OK apache-mod_ldap: draws in apr-util-dbd-ldap-1.5.4-8.mga6, then OK apache-mod_session: draws in apr-util-openssl-1.5.4-8.mga6, but then # systemctl start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. Never seen that before.
This behaviour was detected in other bug report Try to continue installing mods and end with the failed May be other mod ordering issue
CC: (none) => neoser10
Started from scratch again, installing packages each individually in the sequence as listed in Comment 3, but skipping apache-mod_session. All goes well till # urpmi apache-mod_dbd installeren van apache-mod_dbd-2.4.38-1.mga6.i586.rpm vanaf /mnt/updaterpm/i586 Voorbereiden... #################################################################### 1/1: apache-mod_dbd #################################################################### # systemctl start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
@Herman: "mod_dbd manages SQL database connections using apr_dbd". I assume this module needs more configuation to start. It is quite the same for SSL connections in apache, if the certificate does not match, the server won't start. Most of our modules are automatically enabled on install, for my servers I've changed this behaviour like debian does. After installing they need manual enabling, because a missing configuration could stop a running apache instance. For mod_session my apache tells me (/var/log/httpd/error_log): "AH02618: You must load mod_request to enable the mod_auth_form functions" In /etc/apache2/conf/modules.d/00_base.conf this module is disabled by default. After enabling, apache is able to start, even with mod_session.
@Marc While I accept that with fiddling with some configuration settings, one could successfully install this update, I have not experienced an update to apache before which needed this kind of intervention, certainly not on a - as far as apache is concerned - on a blank installation. From what I read from you I even suspect installing this update could even blow an existing working but very basic apache out of the water.
I've experiemented with 2.4.37 (latest in mga6) not the testing version. So at least for mod-session this is already true.
In VirtualBox, M6, Mate, 32-bit Package(s) under test: apache apache-mod_userdir default install of apache & apache-mod_userdir [root@localhost wilcal]# urpmi apache Package apache-2.4.37-1.2.mga6.i586 is already installed [root@localhost wilcal]# urpmi apache-mod_userdir Package apache-mod_userdir-2.4.37-1.2.mga6.i586 is already installed Vbox client webpage can be accessed locally with http://localhost/~wilcal/ and from a browser on the LAN @ http://192.168.0.46/~wilcal/ installing apache-mod_dav, apache-mod_ldap, apache-mod_session & apache-mod_dbd The following 13 packages are going to be installed: - apache-mod_dav-2.4.37-1.2.mga6.i586 - apache-mod_dbd-2.4.37-1.2.mga6.i586 - apache-mod_ldap-2.4.37-1.2.mga6.i586 - apache-mod_session-2.4.37-1.2.mga6.i586 - apr-util-dbd-freetds-1.5.4-8.mga6.i586 - apr-util-dbd-ldap-1.5.4-8.mga6.i586 - apr-util-dbd-mysql-1.5.4-8.mga6.i586 - apr-util-dbd-odbc-1.5.4-8.mga6.i586 - apr-util-dbd-pgsql-1.5.4-8.mga6.i586 - apr-util-dbd-sqlite3-1.5.4-8.mga6.i586 - apr-util-openssl-1.5.4-8.mga6.i586 - libfreetds0-0.95.87-1.mga6.i586 - libpq5-9.6.10-3.mga6.i586 Rebooting system and httpd no longer works nor can it be manually started.
CC: (none) => wilcal.int
In VirtualBox, M6, Mate, 32-bit Package(s) under test: apache apache-mod_userdir default install of apache & apache-mod_userdir [root@localhost wilcal]# urpmi apache Package apache-2.4.37-1.2.mga6.i586 is already installed [root@localhost wilcal]# urpmi apache-mod_userdir Package apache-mod_userdir-2.4.37-1.2.mga6.i586 is already installed Vbox client webpage can be accessed locally with http://localhost/~wilcal/ and from a browser on the LAN @ http://192.168.0.46/~wilcal/ installing apache & apache-mod_userdir from updates_testing The following 3 packages are going to be installed: - apache-2.4.38-1.mga6.i586 - apache-mod_userdir-2.4.38-1.mga6.i586 - meta-task-6-3.3.mga6.noarch reboot Vbox client [root@localhost wilcal]# urpmi apache Package apache-2.4.38-1.mga6.i586 is already installed [root@localhost wilcal]# urpmi apache-mod_userdir Package apache-mod_userdir-2.4.38-1.mga6.i586 is already installed Vbox client webpage can be accessed locally with http://localhost/~wilcal/ and from a browser on the LAN @ http://192.168.0.46/~wilcal/
In VirtualBox, M6, Mate, 64-bit Package(s) under test: apache apache-mod_userdir default install of apache & apache-mod_userdir [root@localhost wilcal]# urpmi apache Package apache-2.4.37-1.2.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi apache-mod_userdir Package apache-mod_userdir-2.4.37-1.2.mga6.x86_64 is already installed Vbox client webpage can be accessed locally with http://localhost/~wilcal/ and from a browser on the LAN @ http://192.168.0.47/~wilcal/ installing apache & apache-mod_userdir from updates_testing reboot Vbox client [root@localhost wilcal]# urpmi apache Package apache-2.4.38-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi apache-mod_userdir Package apache-mod_userdir-2.4.38-1.mga6.x86_64 is already installed Vbox client webpage can be accessed locally with http://localhost/~wilcal/ and from a browser on the LAN @ http://192.168.0.47/~wilcal/
# uname -a Linux localhost 4.14.100-desktop-1.mga6 #1 SMP Fri Feb 15 08:58:09 UTC 2019 i686 i686 i686 GNU/Linux The following 3 packages are going to be installed: - apache-2.4.38-1.mga6.i586 - apache-doc-2.4.38-1.mga6.noarch - apache-mod_ssl-2.4.38-1.mga6.i586 -- after reboot # httpd -v Server version: Apache/2.4.38 (Unix) Server built: Feb 2 2019 20:04:20 I was able to verify the web-server is still running and serving pages
CC: (none) => brtians1
Whiteboard: (none) => MGA6-32-OK
Keywords: (none) => advisory, validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0109.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
MGA7-64 Plasma on Lenovo B50 No installation issues. At CLI: # systemctl -l start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. # journalctl -xe nov 28 14:06:58 mach5.hviaene.thuis systemd[1]: httpd.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit httpd.service has entered the 'failed' state with result 'exit-code'. nov 28 14:06:58 mach5.hviaene.thuis systemd[1]: Failed to start The Apache HTTP Server. -- Subject: A start job for unit httpd.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit httpd.service has finished with a failure. -- -- The job identifier is 2834 and the job result is failed. nov 28 14:07:16 mach5.hviaene.thuis kwin_x11[11687]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 61930, resource id: 102760573, major code: 18 (ChangeProperty), minor c> nov 28 14:07:23 mach5.hviaene.thuis kernel: WARNING: CPU: 1 PID: 30492 at fs/ext4/inode.c:3941 ext4_set_page_dirty+0x3e/0x50 nov 28 14:07:23 mach5.hviaene.thuis kernel: Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache rfcomm ip6t_REJECT nf_reject_ipv6 xt_comment ip6table_mangle> nov 28 14:07:23 mach5.hviaene.thuis kernel: snd_hda_codec_realtek snd_hda_codec_generic mc ledtrig_audio btusb snd_hda_codec_hdmi btbcm btrtl snd_hda_intel intel_rapl_msr snd_hda_codec in> nov 28 14:07:23 mach5.hviaene.thuis kernel: rtsx_pci_sdmmc mmc_block mmc_core xhci_pci xhci_hcd rtsx_pci ehci_pci ehci_hcd usbcore serio_raw sr_mod ttm usb_common i915 wmi i2c_algo_bit dr> nov 28 14:07:23 mach5.hviaene.thuis kernel: CPU: 1 PID: 30492 Comm: kworker/u8:1 Not tainted 5.3.11-desktop-1.mga7 #1 nov 28 14:07:23 mach5.hviaene.thuis kernel: Hardware name: LENOVO 80EW/Lenovo B50-80, BIOS A8CN47WW(V3.00) 07/14/2015 nov 28 14:07:23 mach5.hviaene.thuis kernel: Workqueue: i915 __i915_gem_free_work [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: RIP: 0010:ext4_set_page_dirty+0x3e/0x50 nov 28 14:07:23 mach5.hviaene.thuis kernel: Code: 48 8b 00 a8 01 75 16 48 8b 57 08 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 00 a8 08 74 0d 48 8b 07 f6 c4 20 74 0f e9 a2 81 f8 ff <0f> 0b 48 8> nov 28 14:07:23 mach5.hviaene.thuis kernel: RSP: 0018:ffffa6a4860c7dc0 EFLAGS: 00010246 nov 28 14:07:23 mach5.hviaene.thuis kernel: RAX: 0200000000002036 RBX: ffffe990c5656c40 RCX: 0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: RDX: 0000000000000000 RSI: 000000016f2cd000 RDI: ffffe990c5656c40 nov 28 14:07:23 mach5.hviaene.thuis kernel: RBP: ffff9882e3f4c000 R08: 0000000000000000 R09: ffffffffc04f9600 nov 28 14:07:23 mach5.hviaene.thuis kernel: R10: ffff9882e2820c80 R11: 0000000000000000 R12: 00000000001595b1 nov 28 14:07:23 mach5.hviaene.thuis kernel: R13: ffff9882e440e400 R14: ffff98834c11b930 R15: 0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: FS: 0000000000000000(0000) GS:ffff988356a80000(0000) knlGS:0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 nov 28 14:07:23 mach5.hviaene.thuis kernel: CR2: 00007fb248c7b180 CR3: 000000008b20a003 CR4: 00000000003606e0 nov 28 14:07:23 mach5.hviaene.thuis kernel: Call Trace: nov 28 14:07:23 mach5.hviaene.thuis kernel: i915_gem_userptr_put_pages+0x13d/0x190 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_object_put_pages+0x63/0x90 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_free_objects+0x11a/0x210 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_free_work+0x53/0x80 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: process_one_work+0x200/0x3c0 nov 28 14:07:23 mach5.hviaene.thuis kernel: worker_thread+0x2d/0x3d0 nov 28 14:07:23 mach5.hviaene.thuis kernel: ? process_one_work+0x3c0/0x3c0 nov 28 14:07:23 mach5.hviaene.thuis kernel: kthread+0x112/0x130 nov 28 14:07:23 mach5.hviaene.thuis kernel: ? kthread_create_on_node+0x60/0x60 nov 28 14:07:23 mach5.hviaene.thuis kernel: ret_from_fork+0x35/0x40 nov 28 14:07:23 mach5.hviaene.thuis kernel: ---[ end trace 465ebc2176bfad16 ]---
(In reply to Herman Viaene from comment #18) > MGA7-64 Plasma on Lenovo B50 > No installation issues. > At CLI: > # systemctl -l start httpd Wrong bug, and the kernel error splash should be fixed with kernel-5.3.13-2 that is in bug 25745
CC: (none) => tmb