Security Leftovers

-
Exposing Trojan Source exploits in Emacs [LWN.net]
While the "Trojan Source" vulnerabilities have, thus far, generated far more publicity than examples of actual exploits, addressing the problem still seems like a good thing to do. There are several places where defenses could be put into place; text editors, being the place where developers look at a lot of code, are one obvious example. The discussion of how to enhance Emacs in this regard has made it clear, though, that there are multiple opinions about how an editor should flag potential attacks.
For those just tuning in, one of the Trojan Source vulnerabilities takes advantage of the control codes built into Unicode for the handling of bidirectional text. While this article is written in a left-to-right language, many languages read in the opposite direction, and Unicode-displaying applications must be prepared to deal with that. Sometimes, those applications need some help to know the direction to use when rendering a particular piece of text. Unicode provides control codes to reverse the current direction for this purpose; unfortunately, clever use of those codes can cause program text to appear differently in a editor (or browser or other viewing application) than it appears to the compiler. That can be used to sneak malicious code past even an attentive reviewer.One part of the problem is applications that show code containing overrides in a way that is correct (from a Unicode-text point of view), but which is incorrect in terms of what will actually be compiled. So an obvious solution is to change how applications display such text. It is thus not surprising that a conversation sprung up on the Emacs development list to figure out what the Emacs editor should do.
-
Trojan Source and Python [LWN.net]
The Trojan Source vulnerabilities have been rippling through various development communities since their disclosure on November 1. The oddities that can arise when handling Unicode, and bidirectional Unicode in particular, in a programming language have led Rust, for example, to check for the problematic code points in strings and comments and, by default, refuse to compile if they are present. Python has chosen a different path, but work is underway to help inform programmers of the kinds of pitfalls that Trojan Source has highlighted.
On the day of the Trojan Source disclosure, Petr Viktorin posted a draft of an informational Python Enhancement Proposal (PEP) to the python-dev mailing list. He noted that the Python security response team had reviewed the report and "decided that it should be handled in code editors, diff viewers, repository frontends and similar software, rather than in the language". He agreed with that decision, in part because there are plenty of other kinds of "gotchas" in Python (and other languages), where readers can be misled—purposely or not.
But there is a need to document these kinds of problems, both for Python developers and for the developers of tools to be used with the language, thus the informational PEP. After some adjustments based on the discussion on the mailing list, Viktorin created PEP 672 ("Unicode-related Security Considerations for Python"). It covers the Trojan Source vulnerabilities and other potentially misleading code from a Python perspective, but, as its "informational" status would imply, it is not a list of ways to mitigate the problem. "This document purposefully does not give any solutions or recommendations: it is rather a list of things to keep in mind."
-
Security updates for Thursday
Security updates have been issued by CentOS (kernel, openssh, and rpm), Debian (nss), Fedora (seamonkey), Mageia (glibc), openSUSE (go1.16, go1.17, kernel, mariadb, netcdf, openexr, poppler, python-Pygments, python-sqlparse, ruby2.5, speex, and webkit2gtk3), Oracle (nss), Red Hat (nss), SUSE (clamav, glibc, gmp, go1.16, go1.17, kernel, mariadb, netcdf, OpenEXR, openexr, openssh, poppler, python-Pygments, python-sqlparse, ruby2.1, ruby2.5, speex, webkit2gtk3, and xen), and Ubuntu (nss and thunderbird).
-
Secure communication with Red Hat Decision Manager
Securing communications over networked services is an essential administrative task. This article shows you how to install and configure an SSL certificate to enable HTTPS-secured communication with Red Hat Decision Manager 7.11 on-premises. To minimize the requirements for our example, we will use a self-signed certificate. You can use the same steps with a certificate signed by a certificate authority (CA).
-

- Login or register to post comments
Printer-friendly version- 2062 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is released
After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release.
|
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future Tech
The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world.
Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility.
|
today's howtos
|








.svg_.png)
Content (where original) is available under CC-BY-SA, copyrighted by original author/s.

Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago