SMLR Episode 299 APT Security Update

Posted by Tom Lawrence on January 27, 2019 in Show-mp3, Show-ogg |



Show 299

Contact Us:

show (at) smlr.us or the Contact us page

On the Lawrence Systems Forums




Tony Bemus, Tom Lawrence, Phil Porada and Jay LaCroix

Sound bites by Mike Tanner

Phils GitHub


The LawrenceSystems YouTube Channel Where videos

Jay’s Site


Jay’s Bash Prompt https://pastebin.com/kzPjE8y4

Tech News:


Apt get flaw
“We’re apt to find more problems like this”

“Some package managers should be a snap to secure.”

“I wonder how many more puns will emerge from this”

“I am going to GIT off this topic now..”


KeePass pwnage check



Wine 4.0 Vulkan support. Direct3D 12 support. Game controllers support.



NetBSD hits 100% reproducibility in builds



Someone Hacked PHP PEAR Site and Replaced the Official Package Manager



DHS Orders U.S. Federal Agencies to Audit DNS Security for Their Domains



Superphishing interview attack



FBI arrests PureVPN user with log data that was said to not exist



Oklahoma is NOT OK





Apt Security Update


Max Justicz discovered a vulnerability in APT, the high level package manager.


The code handling HTTP redirects in the HTTP transport method doesn’t properly sanitize fields transmitted over the wire. This vulnerability could be used by

an attacker located as a man-in-the-middle between APT and a mirror to inject malicious content in the HTTP connection. This content could then be recognized as a valid package by APT and used later for code execution with root privileges on the target machine.


Since the vulnerability is present in the package manager itself, it is

recommended to disable redirects in order to prevent exploitation during this upgrade only




The HTTP fetcher process URL-decodes the HTTP Location header and blindly appends it to the 103 Redirect response.


So if the HTTP server sentLocation: /new-uri%0AFoo%3A%20Bar, the HTTP fetcher process would reply with the redirect


Location: /payload%0A%0A201%20URI%20Done%0AURI%3A%20http%3A//deb.debian.org/payload%0AFilename%3A%20/var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg%0ASize%3A%2020070%0ALast-Modified%3A%20Tue%2C%2007%20Mar%202017%2000%3A29%3A01%20%2B0000%0AMD5-Hash%3A%2027967ddb76b2c394a0714480b7072ab3%0AMD5Sum-Hash%3A%2027967ddb76b2c394a0714480b7072ab3%0ASHA256-Hash%3A%20858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831%0AChecksum-FileSize-Hash%3A%2020070%0A


The parent process will trust the hashes returned in the injected 201 URI Done response, and compare them with the values from the signed package manifest. Since the attacker controls the reported hashes, they can use this vulnerability to convincingly forge any package.


Let’s Encrypt



February 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support


As of now, the staging environment has TLS-SNI fully disabled. Let’s Encrypt also disabled the “reuse valid authorizations” feature in staging for the next 30 days. This will ensure that each staging dry run issuance does a fresh validation, so you can be confident that if validation in the staging environment succeeds, your client is working correctly.


Also, Let’s Encrypt is changing the final end-of-life date for TLS-SNI in production to March 13, 2019. This will give more people time to update. We’re going to use the original February 13 date as the beginning of a brownout period: Let’s Encrypt will disable TLS-SNI validation in production on February 13, then re-enable it a week later. Additional brownout periods before the final deprecation may happen.


The goal of the brownout periods is to catch the attention of people who may have missed the notification emails. Not every certificate will necessarily renew during that window, but hopefully enough it will increase the number of people who notice and can update ahead of the deadline.


What can you do?


  1. Confirm your Certbot version is 0.28 or higher. Current version is 0.31
  2. Remove any explicit references to tls-sni-01 in your renewal configuration
  3. Do a full renewal dry run


Steam For Linux Now Lets You Play Windows Games From Other Stores



A hotly requested Steam Play feature recently went live that introduces even more flexibility to Steam’s Proton tool (Proton is an addition to Steam that allows thousands of Windows games to be installed and played directly from the Steam for Linux client.) Users can now launch Windows games purchased on platforms outside of Steam from inside the Steam for Linux client.php




773M Password ‘Megabreach’ is Years Old



Geolocating SSH Hackers In Real-Time



The curious case of the Raspberry Pi in the network closet



This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2011-2023 Sunday Morning Linux Review All rights reserved.
This site is using the Desk Mess Mirrored theme, v2.5, from BuyNowShop.com.