Fedora has issued an advisory on September 27: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/TRPU5CPNMC3QDE5HYMNIHKLJDGKEO4AJ/ Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
mongodb also had to be rebuilt for this update: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/TOKWJX7QHL4HXNYG26CN5STJBMLUZGN5/
Blocks: (none) => 22036
They also updated pdns which had to be rebuilt for this: https://blog.powerdns.com/2018/05/24/powerdns-authoritative-server-4-1-3-released/ https://blog.powerdns.com/2018/08/29/powerdns-authoritative-server-4-1-4-released/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/UTUK5W6EWAMPEK2C57MC46E6QRFHRCKT/
Assigning to the registered maintainer.
Assignee: bugsquad => rverscheldeCC: (none) => marja11
Thanks for the report. The mongdb and pdns rebuilds shouldn't be necessary for us, Fedora's lack of proper libification made the soname change go unnoticed (they updated 0.5.x to 0.6.x, but soname goes from 0.5 to 0.6). For Mageia 6 we have 0.5.1, I'll just patch that directly.
Fixed in Cauldron with yaml-cpp-0.6.2-1.mga7, adding the yet unmerged upstream patch: https://github.com/jbeder/yaml-cpp/pull/489 For Mageia 6 it's a bit trickier as the patch is written in C++11, which mga6's 0.5.1 doesn't use. Adapting it for C++03 is not trivial, but building 0.5.1 with C++11 would likely require rebuilding reverse deps too (and might not work).
Version: Cauldron => 6Whiteboard: MGA6TOO => (none)
Blocks: 22036 => (none)
Found a simpler patch in this SUSE bug report that doesn't require C++11: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-5950 (basically https://github.com/jbeder/yaml-cpp/pull/489/commits without the 4th commit that should have been its own counter proposal PR). It's still good enough for SUSE apparently so I'll go with it too. Advisory: ========= Updated yaml-cpp packages fix security vulnerability The SingleDocParser::HandleNode function in yaml-cpp (aka LibYaml-C++) 0.5.1 allows remote attackers to cause a denial of service (stack consumption and application crash) via a crafted YAML file. (CVE-2017-5950) References: - https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-5950 - https://github.com/jbeder/yaml-cpp/pull/489 RPMs in core/updates_testing: ============================= lib(64)yaml-cpp0.5-0.5.1-6.1.mga6 lib(64)yaml-cpp-devel-0.5.1-6.1.mga6 SRPM in core/updates_testing: ============================= yaml-cpp-0.5.1-6.1.mga6
Assignee: rverschelde => qa-bugs
MGA6-32 MATE on IBM Thinkpad R50e No installation issues # urpmq --whatrequires libyaml-cpp0.5 libopencolorio1 libring0 libyaml-cpp0.5 mongodb mongodb-server openxcom pdns-backend-geoip pdns-backend-geoip Picked openxcom, installed and run it. $ strace -o yamlcpp.txt openxcom It fails with "GEODATA/PALETTES.DAT not found. Make sure you installed openxcom correctly." Checked trace and found calls to libyaml-cpp.so.0.5 on lines 38 thru 52 of 82000+ , so I guess the failure has little to do with the package under test.
CC: (none) => herman.viaene
Installed mongodb $ strace -o yamlcppmongo.txt mongo Ongeldige instructie (geheugendump gemaakt) English: invalid instruction (memory dump made) The trace shows again calls to libyaml-cpp.so.0.5 in the very beginning, but two packages with problems, that's a bit too much of a coincidence for my liking.
The openxcom error is expected, it's a libre engine for a proprietary game, you need to install the original game data as described in /usr/share/doc/openxcom/README.txt. For mongodb, does it work before installing the update candidate?
Downgraded libyaml-cpp0.5 to -0.5.1-6mga6, same results. OK-ing on clean install???
Mageia6, x86_64 Before the update: yaml-cpp already installed. Checking the PoC at https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-5950 CVE-2017-5950 $ g++ -o parse parse.cpp -lyaml-cpp In file included from /usr/include/yaml-cpp/node/node.h:10:0, from /usr/include/yaml-cpp/yaml.h:13, from parse.cpp:6: /usr/include/yaml-cpp/node/ptr.h:10:32: fatal error: boost/shared_ptr.hpp: No such file or directory compilation terminated. $ sudo urpmi lib64boost-devel $ g++ -o parse parse.cpp -lyaml-cpp $ ./parse yaml_stack_overflow.txt yaml-cpp: error at line 1, column 1: end of sequence flow not found $ ulimit -s 1024 $ ./parse yaml_stack_overflow.txt Segmentation fault (core dumped) Updated the two packages and recompiled the parser. $ ./parse yaml_stack_overflow.txt Segmentation fault (core dumped) The upstream discussion hinted that this might not be a reliable test.
CC: (none) => tarazed25
Created attachment 10488 [details] YAML parser for PoC test file
Created attachment 10489 [details] PoC test data for CVE-2017-5950
$ mongo --shell --norc MongoDB shell version: 3.2.5 connecting to: test 2018-11-20T15:44:07.167+0000 W NETWORK [thread1] Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused 2018-11-20T15:44:07.167+0000 E QUERY [thread1] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed : connect@src/mongo/shell/mongo.js:229:14 @(connect):1:6 exception: connect failed $ mongo --shell --norc --nodb MongoDB shell version: 3.2.5 type "help" for help > help db.help() help on db methods [...] > exit bye $ mongo --version MongoDB shell version: 3.2.5 Out of my comfort zone with this and pdns. The mongo shell works, or at least launches, but the PoC test tells us little, so I'm with Herman; should we attempt openxcom? # urpmi openxcom Segmentation fault (core dumped) Help! This is happening all over. Need to reboot.
Logging out and in fixed it.
Re comment #14. The short answer to the question is "no". It looks like installing the infrastructure and data for openxcom is a major undertaking with no guarantee that the UFO game or whatever can be run so I would say this is not for QA unless the user happens to be a games enthusiast. openxcom itself installs cleanly.
Ran strace on the mongo shell and confirmed that yaml-cpp is involved. The library is opened anyway. @herman. We do not have a lot to go on with this update so it would be good if you could run the mongo shell in 32-bits. Any chance you could run this? $ mongo --shell --norc --nodb
mongodb-server starts up OK. $ sudo urpmi mongodb-server [...] installing mongodb-server-3.2.5-3.mga6.x86_64.rpm from /var/cache/urpmi/rpms Creating group mongod with gid 947. Creating user mongod (MongoDB Database Server) with uid 947 and gid 947. $ id mongod uid=947(mongod) gid=947(mongod) groups=947(mongod) $ sudo systemctl enable mongod.service $ sudo systemctl start mongod.service $ systemctl status mongod.service ● mongod.service - High-performance, schema-free document-oriented database Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor prese Active: active (running) since Wed 2018-11-21 10:37:43 GMT; 18s ago Process: 15648 ExecStart=/usr/bin/mongod $OPTIONS (code=exited, status=0/SUCCE Main PID: 15650 (mongod) CGroup: /system.slice/mongod.service └─15650
@Len Comment 17 $ mongo --shell --norc --nodb Ongeldige instructie (geheugendump gemaakt) $ mongo --version Ongeldige instructie (geheugendump gemaakt) I wonder if I am missing some packages??? I'll attach the trace file I made before.
Created attachment 10491 [details] trace file on problem running mongo
There is a considerable difference between your trace and mine Herman. Things are done in a different order but there were no obvious failures to open libraries so there are probably no missing requires. My trace is more verbose, presumably because the command succeeded here. The question is what does this invalid instruction refer to? Since I do not see it, the problem may be architecture related, maybe even at the hardware level. You seem to have hit a bug anyway and probably not related to the yaml library. We need to see what Rémi thinks. Apart from that, I am prepared to give this the 64-bit OK.
Tried one more test, on a local YAML file using the parse command compiled earlier. It copied the contents to STDOUT without raising any exceptions. $ ./parse paddb.yml :font: Larabiefont,15 :default: usb_printer :addressfile: addresses [...] :printer: :HP_Envy_4500: exo :usb_printer: saif :HP_Photosmart5520: okda :file: file :network_printer: okda :HP_Officejet_100: saif :colours: :red: !<!> "#bb4433" :brown: brown [...] The only thing to note there is that twin-hex numbers are prefaced by an extra string: !<!>
Keywords: (none) => feedback
@Herman. No response to the feedback marker so I think I shall remove it and pass the update. There is very little else we could do to test this and it does look OK for 64-bits.
Whiteboard: (none) => MGA6-64-OKKeywords: feedback => (none)
Thanks Herman > Downgraded libyaml-cpp0.5 to -0.5.1-6mga6, same results. exonerates the update. & Len. Validating. Advisory from comment 6.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0471.html
Status: NEW => RESOLVEDResolution: (none) => FIXED