Upstream has issued an advisories on August 3, October 26, and February 1: http://botan.randombit.net/security.html The issues are fixed in 1.10.10 and 1.10.12. Unfortunately the library major has changed from 0 to 1 in the process, so if we just updated it, monotone and softhsm would have to be rebuilt. Further complicating matters, the library subpackage is named incorrectly, which *must* be fixed if it is updated. It has already been updated in Cauldron, and this issue needs to be fixed there. Reproducible: Steps to Reproduce:
Assignee: shlomif => oe
How is the sub package name wrong? Maybe I'm tired.
The library major is 0 in mga5 and 1 in Cauldron, so it shouldn't be called libbotan1.10 in either, it should be libbotan0 in mga5 and libbotan1 in mga6.
Ah. Will fix.
Fixed now.
Thanks Oden! Advisory to come later. monotone and softhsm had to be rebuilt since the botan library's major changed. Updated packages in core/updates_testing: ======================== libbotan1-1.10.12-1.mga5 libbotan-devel-1.10.12-1.mga5 libbotan-static-devel-1.10.12-1.mga5 monotone-1.1-4.1.mga5 softhsm-1.3.4-5.1.mga5 softhsm-devel-1.3.4-5.1.mga5 from SRPMS: botan-1.10.12-1.mga5.src.rpm monotone-1.1-4.1.mga5.src.rpm softhsm-1.3.4-5.1.mga5.src.rpm
Assignee: oe => qa-bugs
Having a look at this one just now. Building an infrastructure for monotone to help with testing.
CC: (none) => tarazed25
Still working on it.
Pre-update stage. There does not appear to be a PoC for the botan issue so all we can do is run monotone or whatever else uses botan. $ urpmq --whatrequires lib64botan1.10 | sort | uniq lib64botan1.10 lib64botan-devel monotone softhsm From man page: monotone - a distributed version control system http://www.monotone.ca/docs mtn is the command associated with mtn. $ locate mtn /usr/bin/mtn /usr/bin/mtn-cleanup /usr/bin/mtnopt Have built a minimal monotone CVS database for three users. Testing with two. I hope to add my "course" notes as an attachment at some stage (setting up the database is a non-trivial operation) so will summarize here. These actions need to be repeated after the update, starting with a clean slate. Framework: using one machine, added two more local users. Think of self as the database administrator or coordinator. monotone expects to find a ~/.monotone directory for each user. No harm in using a symbolic link like: $ mkdir .local/share/monotone $ ln -s .local/share/monotone .monotone Created the databases for each user. Generated the database access key pairs for each user - this is where botan comes in. Defined a project directory for each user (two anyway). Users exported their public keys to user.pubkey files. Users used ssh to transfer their public keys to administrator (! this is a simulation). Administrator places the other users public keys in the database to facilitate checkouts and commits. Administrator starts the database server (listens on port 4691). That is as far as we need go I think. Shall run the update sometime soon.
Correction: mtn is the command associated with monotone.
Moved on to try out softhsm. Managed to initialize a token. The next step was to try to import a key pair. That posed the problem of how do you generate a key pair, adhering to the PKCS#11 standard as well? Could not find any way to do that so shall have to abandon testing softhsm, which means that this update test will be incomplete. ssh-keygen seems to generate the wrong format: $ ssh-keygen -f one Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in one. Your public key has been saved in one.pub. The key fingerprint is: eb:4a:d5:06:c7:b8:ab:da:e6:9c:bc:34:43:17:27:cc lcl@belexeuli $ softhsm --import ~/qa/one.pub --slot 1 --label "test1" --pin 2157 --id FAFF Decoding error: PKCS #8 private key decoding failed Error: Perhaps wrong path to file, wrong file format, or wrong PIN to file (--file-pin <PIN>). $ softhsm --import ~/qa/one.pub --slot 1 --label "test1" --pin #2157 --id FAFF Error: The given user PIN does not match the one in the token. Not the PIN so it looks like "wrong file format" (PKCS#8).
Installed the updates. Not going to try softhsm. Starting on building the monotone databases for the new users. This may take some time.
Don't get too bogged down in it Len If you can get as far as generating keys then it & botan should be OK. First couple of pages here.. http://www.monotone.ca/docs/Tutorial.html#Tutorial Any deeper testing will need to come from the wider community, if anybody uses it.
@claire: Yes, monotone::botan handle the key generation fine and it looks like softhsm is probably OK as well. What I have done with monotone is at a very basic level. Just wanted to establish that it still does what it is supposed to do after the update. That tutorial was my guide all the way through - well laid out. "if anybody uses it" Yeah! Packages updated and similar tests run for the "developer", a user and a networked user. Giving this the thumbs up, on 64 bits. Can we assume that the i586 test can be skipped?
Whiteboard: (none) => MGA5-64-OK
Yes, let's keep things moving. New kernels and isos expected soon. Validating this one then, well done.
Keywords: (none) => validated_updateWhiteboard: MGA5-64-OK => has_procedure MGA5-64-OKCC: (none) => sysadmin-bugs
This needs advisory text/refs please David.
Package list in Comment 5. CVE-2015-7827 is not fixed in this update. Advisory: ======================== Updated botan packages fix security vulnerabilities: The BER decoder would crash due to reading from offset 0 of an empty vector if it encountered a BIT STRING which did not contain any data at all. This can be used to easily crash applicatons reading untrusted ASN.1 data, but does not seem exploitable for code execution (CVE-2015-5726). The BER decoder would allocate a fairly arbitrary amount of memory in a length field, even if there was no chance the read request would succeed. This might cause the process to run out of memory or invoke the OOM killer (CVE-2015-5727). The ressol function implements the Tonelli-Shanks algorithm for finding square roots could be sent into a nearly infinite loop due to a misplaced conditional check. This could occur if a composite modulus is provided, as this algorithm is only defined for primes. This function is exposed to attacker controlled input via the OS2ECP function during ECC point decompression (CVE-2016-2194). The PointGFp constructor did not check that the affine coordinate arguments were less than the prime, but then in curve multiplication assumed that both arguments if multiplied would fit into an integer twice the size of the prime. The bigint_mul and bigint_sqr functions received the size of the output buffer, but only used it to dispatch to a faster algorithm in cases where there was sufficient output space to call an unrolled multiplication function. The result is a heap overflow accessible via ECC point decoding, which accepted untrusted inputs. This is likely exploitable for remote code execution. On systems which use the mlock pool allocator, it would allow an attacker to overwrite memory held in secure_vector objects. After this point the write will hit the guard page at the end of the mmapâed region so it probably could not be used for code execution directly, but would allow overwriting adjacent key material (CVE-2016-2195). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5726 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5727 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2194 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2195 http://botan.randombit.net/security.html
Summary: botan new security issues CVE-2015-572[67], CVE-2015-7827, CVE-2016-219[45] => botan new security issues CVE-2015-572[67] and CVE-2016-219[45]
CC: (none) => davidwhodginsWhiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0102.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
LWN reference for CVe-2015-572[67]: http://lwn.net/Vulnerabilities/679255/
(In reply to David Walser from comment #16) > CVE-2015-7827 is not fixed in this update. CVE-2016-2849 was also not fixed by upstream for 1.10 even though it's affected: http://lwn.net/Vulnerabilities/681390/