Debian-LTS has issued an advisory on February 3: https://www.debian.org/lts/security/2022/dla-2908 Mageia 8 is also affected.
Status comment: (none) => Patches available from DebianWhiteboard: (none) => MGA8TOO
No evident packager for this SRPM, so assigning globally.
Assignee: bugsquad => pkg-bugs
CVE-2021-45343 is actually in libdxfrw (Bug 29720). Fedora has issued an advisory for this on February 12: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/MBLTKH2Q6OBOLSNHIKPW74SFFSC5A2BB/
Summary: librecad new security issues CVE-2021-45341, CVE-2021-45342, CVE-2021-45343 => librecad new security issues CVE-2021-45341 and CVE-2021-45342
Depends on: (none) => 29720
Hi, For Mageia 8, librecad-2.1.3-12.2.mga8 solves the issue. For Cauldron, the build fails with: """ lib/engine/rs_ellipse.cpp:70:22: error: 'tuple' in namespace 'boost::math' does not name a template type 70 | boost::math::tuple<double, double, double> operator()(double const& z) const { | ^~~~~ In file included from lib/engine/rs_ellipse.cpp:49: /usr/include/boost/math/tools/roots.hpp: In instantiation of 'T boost::math::tools::halley_iterate(F, T, T, T, int) [with F = {anonymous}::EllipseDistanceFunctor; T = double]': lib/engine/rs_ellipse.cpp:132:49: required from here /usr/include/boost/math/tools/roots.hpp:681:191: error: no match for call to '({anonymous}::EllipseDistanceFunctor) (double)' 681 | inline T halley_iterate(F f, T guess, T min, T max, int digits) noexcept(policies::is_noexcept_error_policy<policies::policy<> >::value&& BOOST_MATH_IS_FLOAT(T) && noexcept(std::declval<F>()(std::declval<T>()))) | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ """
CC: (none) => nicolas.salguero
Debian has issued an advisory for this on February 15: https://www.debian.org/security/2022/dsa-5077
Suggested advisory: ======================== The updated packages fix security vulnerabilities: A buffer overflow vulnerability in CDataMoji of the jwwlib component of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote Code Execution using a crafted JWW document. (CVE-2021-45341) A buffer overflow vulnerability in CDataList of the jwwlib component of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote Code Execution using a crafted JWW document. (CVE-2021-45342) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45341 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45342 https://www.debian.org/lts/security/2022/dla-2908 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/MBLTKH2Q6OBOLSNHIKPW74SFFSC5A2BB/ https://www.debian.org/security/2022/dsa-5077 ======================== Updated packages in core/updates_testing: ======================== librecad-2.1.3-12.2.mga8 librecad-data-2.1.3-12.2.mga8 librecad-doc-2.1.3-12.2.mga8 librecad-parts-2.1.3-12.2.mga8 librecad-plugins-2.1.3-12.2.mga8 from SRPM: librecad-2.1.3-12.2.mga8.src.rpm
Status: NEW => ASSIGNEDCVE: (none) => CVE-2021-45341, CVE-2021-45342Status comment: Patches available from Debian => (none)Assignee: pkg-bugs => qa-bugsSource RPM: librecad-2.1.3-13.mga9.src.rpm => librecad-2.1.3-12.1.mga8.src.rpmWhiteboard: MGA8TOO => (none)Version: Cauldron => 8
Thank you David and Nicolas. John and Martin, CC, you are using librecad? Can you test?
CC: (none) => fri, johnltw, yullaw
(In reply to Morgan Leijström from comment #6) > John and Martin, CC, you are using librecad? > Can you test? Hi Morgan. Yep, I use it quite regularly. After installing the test candidate, the program started fine. I didn't do any actual "work" with it, but I loaded up several drawings I'd made in the past week, zoomed in/out and around, toggled some layers on/off etc. All appears well. I'll give this my OK. Tested on x86_64. Thanks to everyone for the update.
Thank you John. OKing and validating. Leaf applications of minor updates don't need test on both arch. Advisory in comment 5.
Whiteboard: (none) => MGA8-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => davidwhodginsKeywords: (none) => advisory
Whoops! I've been doing some drawing with the updated packages and *have* run into a post-patch anomaly. In Bug 29720 Comment 0, regarding the libdxfrw library, David said: > Fedora also rebuilt librecad against the updated library, but since we > already switched to the 1.0.1 fork, we probably don't need to. It may yet need to be rebuilt against librecad after all (if it ultimately wasn't). I get the impression that not too many of you are actually familiar with the software, so I won't describe the new issue in greater detail unless asked, but will go so far as to say that placed "blocks" (pre-grouped entities) simply vanish when first imported into a drawing rather than being placed into it. So far as I can tell, the block's data *does* get written into the save file, but fails to appear on-screen in the drawing at all. This suggests to me that the block's entity data is either written into RAM or file in garbled fashion or perhaps the program is failing to re-read the block back from RAM or file correctly. Since reading and writing the DXF data is *exactly* what libdxfrw is meant for, I'm guessing something that was patched has gotten out of sync between it and the librecad application itself.
You got one thing backwards though. Applications get rebuilt against libraries when binary compatibility is broken. Not the other way around. We haven't even patched the library yet.
Removing the validation tag until this is sorted.
Keywords: validated_update => (none)
It should be retested once the library is patched anyway.
Removing the MGA8-64-OK too. For testers, note that this should be tested in conjunction with the update from bug 29720
Whiteboard: MGA8-64-OK => (none)
Adding the feedback tag so it's clear on http://madb.mageia.org/tools/updates that testing of this update is on hold for now.
Keywords: (none) => feedback
(In reply to David Walser from comment #10) > You got one thing backwards though. Applications get rebuilt against > libraries when binary compatibility is broken. Not the other way around. I knew that, and you're right of course. I can't tell you how I managed to say what I meant completely in reverse. Not that it matters. It turns out that my entire complaint in Comment 9 was a false alarm. What I describe there *is* a bug for sure, but one for upstream. It has no bearing on our current context. Deciding I'd wait for the next test candidate, I downgraded LibreCAD back to package 12.1, but the problem remained. Clearly something else was causing it. When I moved my config file out and started the application "fresh-from-factory" the problem was gone. Putting my config file back, the problem returned. It took a bit of scrolling up and down in the config to locate the real issue, but I found it. The actual bug is pretty wacky. When you insert an external block, a special toolbar temporarily appears. This toolbar presents you with two options to apply to the block, each accompanied by an entry box. The two options are "Rotation Angle" and "Scaling Factor". Obviously both entry boxes are meant to take only numbers, but stupidly, they don't appear to validate their input in any way, such that you can type in "foobar" and they'll happily accept it. Not surprisingly, putting text into a numeric entry field will cause unexpected and undesirable behaviour. All changes to LibreCAD's settings are immediately saved to its config file so it will "remember" them for the next time you use that same tool, but since this special toolbar is context specific, it's dismissed the moment you're done importing the new block, and if you've failed to notice you'd input gibberish while it was still visible... voila! A great recipe for future annoyance. In my case, the Scaling Factor had become set to "se", which happens to be the command-key shortcut for "Snap-to-Endpoints". I must have set a block to a new Rotation Angle and then TAB keyed from that box into, but not out of, its neighbouring Scaling Factor box and typed "se" without realizing that the text cursor was still trapped there. That all this happened only *after* installing our 12.2 test candidate was nothing more than an unfortunate coincidence. I've updgraded back to 12.2 and everything is working as expected again -- even without an updated libdxfrw library. What this bug ultimately places into the saved drawing file is a still a mystery to me. Presumably the inserted blocks *vanish* from view because a scale factor of "foobar" is what? Zero? Whatever it does, or wherever the blocks go, can't be good news. I guess I'll go swimming upstream... Anyway, I'm sorry for wasting everyone's time with all this confusion, and also sorry I had to waste my own time explaining it. :-/ I'm not sure what you all will want to do regarding the update validation now, but it looks good to me again.
Great hunting! Yes upstream should certainly like to fix that dialogue. Per comment 12 I think we should wait for bug 29720.
libdxfrw is updated, so this can be tested.
Keywords: feedback => (none)
I've tested the updates from both bugs as far as the most basic function is concerned, but I definitely do not have the kind of experience with libreCAD that John L. obviously has. I would be happier if John L. could take another look with the new libdxfrw, but considering Comment 15 if my simple test is sufficient we can send them on, I suppose.
CC: (none) => andrewsfarm
Ouch! Unfortunately it's no good for me. I now get an instantaneous crash to desktop: ┌──── │ $ librecad │ RS_DEBUG::setLevel(3) │ RS_DEBUG: Critical │ RS_DEBUG: Errors │ RS_DEBUG: Warnings │ Segmentation fault (core dumped) └──── Combined test candidates from both this bug (LibreCAD) and bug 29720 (libdxfrw) are installed: ┌──── │ $ rpm -qa *librecad* *dxfrw* │ librecad-parts-2.1.3-12.2.mga8 │ librecad-data-2.1.3-12.2.mga8 │ librecad-plugins-2.1.3-12.2.mga8 │ librecad-2.1.3-12.2.mga8 │ librecad-doc-2.1.3-12.2.mga8 │ lib64dxfrw1-1.0.1-1.1.mga8 └──── I've been running the LibreCAD candidate without further issues since my last comment on 2020-03-03 so the *only* thing that changed is the libdxfrw candidate. Sorry but I'm in a bit of a rush just now. Is there something else I've overlooked and neglected to install/update?
Okay, so my current issue seems related to something in my config. I moved my ~/.config/LibreCAD/LibreCAD.conf elsewhere and now the program will start successfully *without* the segfault. Unfortunately I don't have time to investigate further right now. :-/
Ungh! Because this new headache was bothering me so much I've turned my attention to it when I really should be working on something else. Anyway the tl;dr is that the library update candidate is a *complete* train wreck! :-( I quickly narrowed the problem in my config down to the [Paths] section. Specifically, the hangup was the "Template=" line which tells LibreCAD where to find the user's custom default DXF template that it's meant to load on startup. Uh oh! I removed my "Template=" line. LibreCAD started successfully with a very blank and vanilla (no predefined layers, no drawing title block, etc.) work area. I closed this and pulled up the file browser to *open* one of my recent drawings. After selecting one, I clicked "OK"... *BOOM!* segfault. I started the program up again. I drew a simple rectangle. I opened the "Save As" dialog, assigned it a name, clicked "OK"... *BOOM!* segfault. And there you have it. Presumably the "rw" in libdxfrw stands for DXF "read/write" so it's clearly somehow failing its most fundamental function. Though it *did* output a file with the assigned name containing what looks like DXF data, I currently have no way of seeing what it looks like as LibreCAD itself doesn't survive the process. I didn't see a new LibreCAD candidate in the testing repo. Wasn't one supposed to be built against the new library? Is that what I'm missing?
Yes, librecad might need a rebuild.
(In reply to David Walser from comment #22) > Yes, librecad might need a rebuild. No registered maintainer, Assinging to all.
Assignee: qa-bugs => pkg-bugs
Updated packages in core/updates_testing: ======================== librecad-2.2.0-0.rc3.1.mga8 librecad-data-2.2.0-0.rc3.1.mga8 librecad-doc-2.2.0-0.rc3.1.mga8 librecad-parts-2.2.0-0.rc3.1.mga8 librecad-plugins-2.2.0-0.rc3.1.mga8 from SRPM: librecad-2.2.0-0.rc3.1.mga8.src.rpm
Assignee: pkg-bugs => qa-bugs
(In reply to Nicolas Salguero from comment #24) > Updated packages in core/updates_testing @Nicolas : The latest 2.2 release candidate, huh? Ooooh, shiny. I've installed it, it starts okay, and my drawings appear to load without issue. A nitpick about the RPM as it is though: on selecting the main package, it neglects to pull in its other component packages automagically (i.e. the data, doc, parts, and plugins). It also fails to take along the new libdxfrw candidate as it should. I had to select all of them individually. Stranger still, LibreCAD and its dependencies normally have a payload of ~84MiB (on x86_64) but the total for this candidate came in at less than half of that. It was weird to see rpmdrake say "40+MiB will be freed" prior to the install. The program seems to work though, and from a look through /usr/share/librecad/ everything I would expect to be there appears to be in its proper place (so far as I can remember). Still, I can't help wondering where the other 40+MiB went. More efficient use of shared libraries maybe? @David and Morgan : I'm pretty hesitant about giving this new candidate an immediate thumbs up. Given that this is an upstream RC, I anticipate all sorts of bugs and other weirdness. There are some obvious UI alterations with this new version too (most notably, at first glance, on the layers panel), plus there's now some sort of "Pen Wizard" thinger-majigger that I know absolutely nothing about. Could I perhaps take a few days... maybe a week... to run it through its paces and figure out what's changed before reporting back?
Given the cve entries describe Remote Code Execution using a crafted JWW document the sooner the better. Not requiring the doc, etc. is not that unusual, as not everyone will need them and may not have the extra space. They should probably be suggests, but that can be requested in a new bug report, as that should not hold up a remote code execution fix. As this bug depends on bug 29720, it will not be pushed from updates testing to updates without libdxfrw being pushed first, or at the same time. Anyone who is installing updates using auto-select, auto-update, or normal rpmdrake usage, who has both librecad and libdxfrw will get both. Based on comment 25, I'm going to go ahead and ok/validate this update and the libdxfrw update, as basic functionality is working, even if there may be other problems found later.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OK
(In reply to Dave Hodgins from comment #26) > Given the cve entries describe Remote Code Execution using a crafted JWW > document the sooner the better. @Dave : Okay, I'll try to play around with it a bit over the next day or two. > Not requiring the doc, etc. is not that unusual I hear you, but it seemed odd since, in the past, installing LibreCAD's base package *always* pulled in its other component parts with it. And after the roller-coaster ride I described in comment 21, libdxfrw should be mandatory because the program appears to need it in order to open/save drawings. Anyway, regarding the discrepancy with the payload I mentioned in comment 25: the 2.1.3 and 2.2.0 data packages weigh in at 8.3 and 3.0 MiB respectively. Some i18n stuff got added to the new one, but it's missing wqy-unicode.lff from its fonts subfolder. This file contains the WenQuanYi Zen Hei characters needed for CJK text, and unpacked, it on its own accounts for the missing 42MiB. I don't know how many Mageians need East Asian character support, but somehow it got left out.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0152.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
(In reply to John L. ten Wolde from comment #27) > I hear you, but it seemed odd since, in the past, installing LibreCAD's base > package *always* pulled in its other component parts with it. And after the > roller-coaster ride I described in comment 21, libdxfrw should be mandatory > because the program appears to need it in order to open/save drawings. > > Anyway, regarding the discrepancy with the payload I mentioned in comment > 25: the 2.1.3 and 2.2.0 data packages weigh in at 8.3 and 3.0 MiB > respectively. Some i18n stuff got added to the new one, but it's missing > wqy-unicode.lff from its fonts subfolder. This file contains the WenQuanYi > Zen Hei characters needed for CJK text, and unpacked, it on its own accounts > for the missing 42MiB. I don't know how many Mageians need East Asian > character support, but somehow it got left out. Please do open a new bug report for those issues. It should be high priority, but not critical as this one was.
For comment 29: Followup Report: Bug 30379 And https://bugs.mageia.org/show_bug.cgi?id=30521#c12 To be continued there at Bug 30521