- openSUSE Security

[opensuse-security] Firewall on a labtop as private web / mail server
by Patrick Serru 04 Oct '17

04 Oct '17

Hello everyone, I hope I am asking on the good list. Excuse me, please, if not. This is strange, but on the 5 Leap 42.3 installations on a labtop Compaq Presario C700, the last two did me the honor to ask me the configuration of the network, and not the first three. Can anyone tell me, please, why the installation may require configuration, immediately after the choice of language and layout of the keyboard ? The choice of a minimal installation, perhaps. After this minimal installation for a text-based operation, online updating, adding to the minimum system of XOrg-X11 and tigervnc, having banned the "yast2-firewall" and "network manager" packages, the system reboots and works correctly, with wifi interfaces and Ethernet still in the desired configuration. Here is a shema of installation : ____ eth0 ____ | |<---------------->| | |desk| .-->|hub | |top | eth1 | | | |____|<--. | |____| | | 192.168.0.0 ______ eth1 | | _____ _/ \_ 198.168.1.0 | .-->| | ( ) | |modem|---->( INTERNET ) eth0 | |cable| (_ _) ____ | |_____| \______/ | |<--’ eth0 ^ |lab | | | top| wlan0 . 192.168.0.0 |____|<--.... .... Can anyone help me, please, to set up the labtop firewall, with the file /etc/sysconfig/SuSEfirewall2 ? Here is the contents of this file for my last attempt: FW_DEV_EXT="wlan0" FW_DEV_INT="eth0" FW_DEV_DMZ="" FW_ROUTE="no" FW_MASQUERADE="no" FW_MASQ_DEV="" FW_MASQ_NETS="" FW_NOMASQ_NETS="" FW_PROTECT_FROM_INT="" FW_SERVICES_EXT_TCP="http https 587 imap" FW_SERVICES_EXT_UDP="53" All other parameters contain their default values (either empty, or empty strings). My goal is to allow all the traffic on the network 192.168.1.0 (eth0) and limit that from the outside (wlan0) to http, https, 587 and imap. The labtop must of course be able to resolve domain names (DNS). I thank you for the attention you paid ti this e-mail. Sincerly, Patrick Serru -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 2

[opensuse-security] does CVE-2017-9798 affect us?
by Mathias Homann 27 Sep '17

27 Sep '17

Hi, just came across https://arstechnica.com/information-technology/2017/09/ apache-bug-leaks-contents-of-server-memory-for-all-to-see-patch-now/, does CVE-2017-9798 affect openSUSE/SLES/SLED? Cheers Mathias -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann(a)openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

3 3

[opensuse-security] security holes in nvidia driver
by Mathias Homann 27 Sep '17

27 Sep '17

Hi guys, this just in: http://nvidia.custhelp.com/app/answers/detail/a_id/4544 Seems that there are several security-relevant holes in nvidia drivers that can be exploited to gain local root access. Please update the provided drivers to the versions listed on that page or better quickly. Cheers Mathias -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 1

[opensuse-security] Doubt on the security model of OBS repo signing
by star＠aosc.io 18 Sep '17

18 Sep '17

## Prelude Recently I received checksum error during system upgrade, something like this: > 2017-09-11 20:28:48 <1> brilliant-laptop(25623) [zypp++] > MediaCurl.cc(log_redirects_curl):135 redirecting to Location: > http://ftp-srv2.kddilabs.jp/Linux/packages/opensuse/tumbleweed/repo/oss/sus… > 2017-09-11 20:28:48 <2> brilliant-laptop(25623) [FileChecker] > FileChecker.cc(operator()):64 File > /var/cache/zypp/packages/repo-oss/suse/noarch/qemu-sgabios-8-1.1.noarch.rpm > has wrong checksum sha1-1f96e12b066af531cec4d104fa4522966fb8af4f > (expected sha1-18f04703e82b012340400398f0b7404b07b77769) I think my ISP might have a transparent proxy server to save their bandwidth, and the file on that proxy server might be broken. I have been even once offered a corrupted installer ISO! (which installed without any error in a test VM.) I am not sure if I am suffering from a deliberate MITM attack. So I spent some time investigating the security model of openSUSE package delivering. ## Investigation I set up Wireshark and some other tools to capture the network data. Here are my findings. (If anything below is wrong, please tell me.) - All official repos (repo-debug, repo-non-oss, repo-oss, repo-source, repo-update) are HTTP, but their GPG keys are preloaded in the installer ISO. If the user checksums their installation media, this will be safe enough. - If the user choose to One-Click-Install an "unstable package" on software.opensuse.org, the ymp script is served in HTTPS, but OBS repository URLs are HTTP by default. - OneClickInstallUI fetches repomod.xml.key in plain HTTP, and asks the user whether to "Import Untrusted GPG Key". - It is not easy to check whether the GPG key is correct by hand & eye. At least it is not one-click-available, since the "GPG Key / SSL Certificate" button is only visible on the page of your own OBS project. - It is lucky that repomod.xml.key is not distributed to 3rd-party mirrors by MirrorBrain. Although mirrors can do no evil to the key, it might still be vulnerable to an MITM attack. Conclution, official repos are safe, but OBS repos are something we might be careful. Although openSUSE is not responsible for the quality of the software in user repos, it had better to lengthen the shortest stave on the security barrel for the user. ## Suggestions It might be difficult to modify the current architecture. I want to suggest some ways to make it better. I am not sure if they works, let's just discuss them. 1. Embedding the GPG key in ymp script. This might require modification to OneClickInstallUI, and it is safe once ymp is served with HTTPS. Any 3rd-party repo may benefit from the feature by embedding their keys. 2. Showing GPG key in a place where the user can never miss it. Also educate the user to check it. This include not hiding the "GPG Key / SSL Certificate" button to repo not owned by oneself. In addition, put it on both build.opensuse.org and software.opensuse.org. 3. Alternatively, serving the repo metadata in HTTPS, but packages in HTTP. This requires least modification to the client. Since repomod.xml.key is already bypassing MirrorBrain, simply modify the repo's URL to HTTPS will make it safe. As side-effects, it will increase the load to download.opensuse.org server, and will increase the time required to do a "zypper refresh". Anyway, if I made any mistake in this mail, please tell me. I hope openSUSE could be more secure and easier to use. -- StarBrilliant -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 3

[opensuse-security] (Past) S/MIME(!) encryption problem with openSUSE 42.1/42.2 + Thunderbird 52 + Enigmail <1.9.7 (openSUSE-RU-2017:1363-1)
by 686f6c6d 25 Aug '17

25 Aug '17

Greetings (and sorry for this really late mail), I am not sure if this mailing list is the correct address for this, but it affected openSUSE, and you probably know better than me if and how to contact the Thunderbird and Enigmail developers… TLDR: Back in May (2017-05) we noticed the following problem on openSUSE Leap 42.1 and 42.2 with Thunderbird 52 and RPM-installed Enigmail: E-Mail that should have been X.509-signed or -encrypted was sent entirely unencrypted and unsigned, with Thunderbird giving no indication that signing or encrypting had failed. = Our setup = - All of our laptop-using colleagues have personal X.509 certificates on PKCS#11 USB tokens. - Some of them also have personal GPG keys on their laptops or tokens. - Thunderbird signs outgoing mail by default with the X.509 certificate. - Thunderbird encrypts on demand with either X.509 (S/MIME) or GPG key (via Enigmail). = What happened, what was the problem? = - If our users tried to read GPG-encrypted mail in their freshly updated Thunderbird 52, or sign or encrypt via GPG, or even change their Enigmail/GPG config, it failed noisily. So far, so good, this was reported by somebody else 2 days after the release of TB52 as BSC#1038034 (URL in timeline section below). - If our users tried to send S/MIME-signed and/or -encrypted mail, it was "successfully" sent without any error message, but unsigned and unencrypted (reading mail---decrypting and verifying---worked fine). So apparently the fact that Enigmail/GPG encryption was incompatible with Thunderbird 52 broke the whole Thunderbird crypto, including X.509/S-MIME, in such a horrible, invisibly way. (We witnessed this on several laptops and reproduced it with newly created Thunderbird user profiles. Sadly, I don't have any strace because I didn't think of it at the time, and when I did, all users had upgraded. But I assume the problem will return in the future.) = Timeline = 2017-05-06 Release of Thunderbird 52 on openSUSE Leap 42.1 and 42.2 2017-05-08 Bugreport (not by us) that Enigmail isn't working anymore with Thunderbird 52 (https://bugzilla.suse.com/show_bug.cgi?id=1038034, similar reports existed for previous Thunderbird versions) 2017-05-17 EOL openSUSE Leap 42.1, didn't receive a fix. 2017-05-19 Enigmail update for 42.2 only (openSUSE-RU-2017:1363-1, https://lists.opensuse.org/opensuse-updates/2017-05/msg00071.html) = Who was affected? = All of our laptop users running openSUSE 42.1 or 42.2 at that time, - if they had installed the RPM package "enigmail", - if they had updated to Thunderbird 52 (at or after 2017-05-06), - if they hadn't yet updated to Enigmail 1.9.7 (at or after 2017-05-19). (To see if you are/were affected, you should: 1. identify the timespan between installation/update of MozillaThunderbird 52 and Enigmail 1.9.7: grep -i "enigmail\|thunderbird|52" /var/log/zypp/history 2. look through your Thunderbird "Sent" folder for that timespan and see if mails that were supposed to be S/MIME-signed or -encrypted really are signed or encrypted.) = How to get rid of the problem? = Users of openSUSE Leap 42.1 need(ed) to: - remove the system package "enigmail" ("zypper rm enigmail" as root) to avoid similar problems with future Thunderbird updates and - if you do need GPG, install the Thunderbird Add-On of the same name (Extras -> Add-ons -> enter "enigmail" into the search field in the top right -> Enter) and - upgrade to at least 42.2 as soon as possible. Users of 42.2 need(ed) to: - install current system package updates after 2017-05-19 ("zypper ref -f; zypper up" as root; make sure enigmail is at least version 1.9.7) and we recommended to our users to also: - remove the system package "enigmail" (like above) and - if you do need GPG, install the Thunderbird Add-On of the same name (like above). = How to avoid similar problems in the future? = - Fix Thunderbird and/or Enigmail upstream to at least not break silently. - Release openSUSE Thunderbird updates together with Enigmail updates, or introduce a version dependency if possible (I assume it is not that easy on the RPM package level because Enigmail probably works with other Mail client software, too, and hence a dependency on Thunderbird at all would be nonsensical). Thanks for your time and for making openSUSE! -- Kind regards Christopher 'm4z' Holm / 686f6c6d "We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart." --H. L. Mencken -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0

[opensuse-security] Re: [security-announce] SUSE-SU-2017:2225-1: important: Security update for git
by tedrb＠wellsfargo.com 21 Aug '17

21 Aug '17

We don't have git installed anywhere. Doubtless there's some very expensive vendor package that's the company standard instead. Patching on the fly would take restarting any running processes; I don't know if there are such things with a typical git setup. CVE-2017-1000117 has a VSS score of 9.3 inflated from Suse's estimate of 5.8, so it's due 20 Oct. Ted On Mon, 2017-08-21 at 18:07 +0200, opensuse-security(a)opensuse.org wrote: SUSE Security Update: Security update for git ______________________________________________________________________________ Announcement ID: SUSE-SU-2017:2225-1 Rating: important References: #1052481 Cross-References: CVE-2017-1000117 Affected Products: SUSE Studio Onsite 1.3 SUSE Linux Enterprise Software Development Kit 11-SP4 SUSE Linux Enterprise Debuginfo 11-SP4 ______________________________________________________________________________ An update that fixes one vulnerability is now available. Description: This update for git fixes the following issues: - CVE-2017-1000117: an argument injection in SSH URLs could lead to client-side code execution (bsc#1052481) Patch Instructions: To install this SUSE Security Update use YaST online_update. Alternatively you can run the command listed for your product: - SUSE Studio Onsite 1.3: zypper in -t patch slestso13-git-13235=1 - SUSE Linux Enterprise Software Development Kit 11-SP4: zypper in -t patch sdksp4-git-13235=1 - SUSE Linux Enterprise Debuginfo 11-SP4: zypper in -t patch dbgsp4-git-13235=1 To bring your system up-to-date, use "zypper patch". Package List: - SUSE Studio Onsite 1.3 (x86_64): git-1.7.12.4-0.18.3.1 git-core-1.7.12.4-0.18.3.1 - SUSE Linux Enterprise Software Development Kit 11-SP4 (i586 ia64 ppc64 s390x x86_64): git-1.7.12.4-0.18.3.1 git-arch-1.7.12.4-0.18.3.1 git-core-1.7.12.4-0.18.3.1 git-cvs-1.7.12.4-0.18.3.1 git-daemon-1.7.12.4-0.18.3.1 git-email-1.7.12.4-0.18.3.1 git-gui-1.7.12.4-0.18.3.1 git-svn-1.7.12.4-0.18.3.1 git-web-1.7.12.4-0.18.3.1 gitk-1.7.12.4-0.18.3.1 - SUSE Linux Enterprise Debuginfo 11-SP4 (i586 ia64 ppc64 s390x x86_64): git-debuginfo-1.7.12.4-0.18.3.1 git-debugsource-1.7.12.4-0.18.3.1 References: https://www.suse.com/security/cve/CVE-2017-1000117.html https://bugzilla.suse.com/1052481 N��r��y隊Z)z{.��r��/��˛��m�)z{.��+�:�{Zr�az�'z��j)h��Ǭy˫�ܾ� ޮ�^�ˬz��

1 0

[opensuse-security] Weired result of a ssl test page with my 42.3 Leap laptop (Lenovo)
by stakanov＠freenet.de 02 Aug '17

02 Aug '17

Given the problems of spyware installed on Lenovo I checked time ago on badssl with a page controlling for superfish etc. This is now running on https://badssl.com/dashboard/ When I run that page, all is OK but one value that comes out faulty. AFAIU my system responds (with FF) to a page in a way it shouldn't. Exactly with a DH1024. Which reads on the site as: This site uses an ephemeral Diffie-Hellman key exchange over a 1024-bit group. I looked it up in Google but did find only that this has been a problem in the past. Could anybody inform me if this is: a) a Leap problem b) a FF problem c) a problem of my laptop (e.g. Intel Management Engine Interface? - it shouldn't as it has been deactivated in the BIOS). Maybe someone could check if this happens on other Leap systems (time ago that was the same with konqueror which was vulnerable to poodle (apparently via QT webkit if I did understand well, that should be fixed however). Thank you. Mit freenet Mail sicher kommunizieren! [https://email.freenet.de/emig/index.html?utm_medium=Text&utm_source=Footers…] Wir garantieren Ihnen verschlüsselte Datenübertragung & Datenspeicherung auf deutschen Servern - E-Mail made in Germany! -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 1

[opensuse-security] Tumbleweed /etc/permissions*
by mh＠mike.franken.de 14 Jul '17

14 Jul '17

Hi *, I have a few question regarding the files /etc/permissions* and chkstat on a Tumbleweed system: According to the man pages and docs, chkstat is called whenever a configuration change was made. And chkstat should look into /etc/sysconfig/security to find the permissions.<type> file(s) to use. I have configured PERMISSION_SECURITY="easy local" PERMISSION_FSCAPS="yes" in my /etc/sysconfig/security file so chstat should use /etc/permissions.easy and /etc/permissions.local and it should honour capability settings in these files. In /etc/permissions.local I have /usr/bin/gnome-keyring-daemon root:root 0755 +capabilities cap_ipc_lock=+ep But everytime an update for the gnome-keyring package gets installed, the keyring daemon misses the configured capabilities. So obviously chkstat isn't called in this case. What configurations changes are meant by the docs then? Shouldn't zypper also call chkstat after installation of all new packages? Or do I misunderstand the intention of the permissions package including chkstat? Thx and bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 5

[opensuse-security] serious flaw in libgcrypt?
by Mathias Homann 05 Jul '17

05 Jul '17

Hi guys, https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000408.html and https://www.heise.de/security/meldung/Seitenkanalangriff-RSA-Verschluesselu… (in german) Do we have that in Leap 42.2? Will we get that? Cheers MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C

3 3

[opensuse-security] Unsubscribe
by Søren Kent Jensen 04 Jul '17

04 Jul '17

Unsubscribe -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0