Why you should not use Outlook as an email client:
If you ae unfortunate to have AT&T as your provider:
Data of nearly all AT&T customers downloaded in security breach Data of nearly all AT&T customers downloaded in security breach | Cybersecurity News | Al Jazeera
TeamViewer Corporate network hacked by Russian Hackers:
Whilst TeamViewer are stating no customer details have been leaked, found an old article from 2016 where hackers attacked users of TeamViewer:
2 Likes
Here is an interesting article on the developer who wrote the first shim for Linux kernel to boot in UEFI years ago about the current SBAT fiasco. I am not posting the page/title as it includes an expletive that would prevent me from posting:
" Long version: When UEFI Secure Boot was specified, everyone involved was, well, a touch naive. The basic security model of Secure Boot is that all the code that ends up running in a kernel-level privileged environment should be validated before execution - the firmware verifies the bootloader, the bootloader verifies the kernel, the kernel verifies any additional runtime loaded kernel code, and now we have a trusted environment to impose any other security policy we want. Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash even if it's signed with a trusted key.
Unfortunately, as it turns out, scale. Every Linux distribution that works in the Secure Boot ecosystem generates their own bootloader binaries, and each of them has a different hash. If there's a vulnerability identified in the source code for said bootloader, there's a large number of different binaries that need to be revoked. And, well, the storage available to store the variable containing all these hashes is limited. There's simply not enough space to add a new set of hashes every time it turns out that grub (a bootloader initially written for a simpler time when there was no boot security and which has several separate image parsers and also a font parser and look you know where this is going) has another mechanism for a hostile actor to cause it to execute arbitrary code, so another solution was needed.
And that solution is SBAT. The general concept behind SBAT is pretty straightforward. Every important component in the boot chain declares a security generation that's incorporated into the signed binary. When a vulnerability is identified and fixed, that generation is incremented. An update can then be pushed that defines a minimum generation - boot components will look at the next item in the chain, compare its name and generation number to the ones stored in a firmware variable, and decide whether or not to execute it based on that. Instead of having to revoke a large number of individual hashes, it becomes possible to push one update that simply says "Any version of grub with a security generation below this number is considered untrustworthy".
So why is this suddenly relevant? SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we've seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.
(An aside: the "Something has gone seriously wrong" message that's associated with people having a bad time as a result of this update? That's a message from shim, not any Microsoft code. Shim pays attention to SBAT updates in order to avoid violating the security assumptions made by other bootloaders on the system, so even though it was Microsoft that pushed the SBAT update, it's the Linux bootloader that refuses to run old versions of grub as a result. This is absolutely working as intended)
The problem we've ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it's worth noting that grub is signed by individual distributions, not Microsoft, so there's no externally introduced lag here). Microsoft's stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn't work as intended and at least some dual-boot setups applied the update and that distribution's Shim refused to boot that distribution's grub.
What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems. The distribution-provided Shim first-stage bootloader read this variable, read the SBAT section from the installed copy of grub, realised these conflicted, and refused to boot grub with the "Something has gone seriously wrong" message. This update was not supposed to apply to dual-boot systems, but did anyway. Basically:
- Microsoft applied an update to systems where that update shouldn't have been applied
- Some Linux distros failed to update their grub code and SBAT security generation when exploitable security vulnerabilities were identified in grub
The outcome is that some people can't boot their systems. I think there's plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they're updating those and updating the security generation to match, because otherwise they're shipping a vector that can be used to attack other operating systems and that's kind of a violation of the social contract around all of this.
It's unfortunate that the victims here are largely end users faced with a system that suddenly refuses to boot the OS they want to boot. That should never happen. I don't think asking arbitrary end users whether they want secure boot updates is likely to result in good outcomes, and while I vaguely tend towards UEFI Secure Boot not being something that benefits most end users it's also a thing you really don't want to discover you want after the fact so I have sympathy for it being default on, so I do sympathise with Microsoft's choices here, other than the failed attempt to avoid the update on dual boot systems.
Anyway. I was extremely involved in the implementation of this for Linux back in 2012 and wrote the first prototype of Shim (which is now a massively better bootloader maintained by a wider set of people and that I haven't touched in years), so if you want to blame an individual please do feel free to blame me. This is something that shouldn't have happened, and unless you're either Microsoft or a Linux distribution it's not your fault. I'm sorry."
2 Likes
Just found these nuggets:
Critical vulnerability in Firefox
1 Like
Which has been fixed:
"Security Vulnerability fixed in
Firefox 131.0.2,
Firefox ESR 128.3.1,
Firefox ESR 115.16.1"
(From link in previous post).
2 Likes
Just seen this in another thread.
Found out about this earlier:
https://sharpsec.run/rce-vulnerability-in-qbittorrent/
All versions up to 5.0.0 are vulnerable. 5.0.1 is fixed. The article also warns against using the built-in update prompt, but to instead download it manually (or I guess via the software store).
-
On Windows, it will download and execute a Python installer from a hardcoded URL without doing any verification steps or even asserting the SSL certificate.
-
On Windows and linux, excluding AppImage releases, it will pull an XML file from a hardcoded URL without doing any verification steps or even asserting the SSL certificate, and then ask the user to open another URL contained within the XML file in their browser to initiate a file download.
-
On all platforms and releases, no verification or checks are performed on the RSS feeds added by users, or their contents, and it will simply download whatever URL is in the feed entry you double-click.
-
On all platforms and releases, it will download and extract a compressed GeoIP database from a hardcoded URL, apparently again without any sort of verification.
This is why on some other distributions there is a security warning using proprietary blobs. I always stick to nouveau drivers because I am not a heavy gamer.
Brought back memories of sorting out a student's notebook who had been using qbitorrent for all sorts of downloads and got a virus. The only torrent client I have ever used is Deluge. But I don't do torrents these days.
I use torrents a lot for linux ISOs. Not sure why, but I am compelled to keep a selection of them to hand and regularly download the latest for a selection of distros including Zorin, Ultramarine, Fedora (Workstation, i3, Kinoite), Kali Everything, Manjaro (KDE, Xfce), LMDE, MX Linxu (KDE, Xfce), Ubuntu LTS. I also have a few I plan to try out soon like Qubes, PCLinuxOS, and Q4OS.
2 Likes
I am aware that in the past some distributions were only available via torrent. I would still opt for Deluge if I had to use it. Basically what I do is download the .iso over broadband, then copy the iso to my ventoy multiboot usb stick.
Latest Linux security news about Chrome and Chromium flaws/bugs:
The hero we need. Especially these days, torrenting and decentralization is becoming increasingly necessary.
Any members from the US, please start contacting your representatives to reverse the decision to stop funding of CVE. Just had this disturbing mailshot from The Register:
Additionally, anyone running Linux on an Intel powered machine, make sure to apply critical updates to the kernel you are running as there is a Spectre V2 about:
We can try but it will fall on deaf ears...
Actually, funding has been extended for a year, and a non-profit is being formed to pick up the rather preposterous amount of slack.
2 Likes
I have just seen this thread for the first time, but I don't know enough about Linux to appreciate much of what is being discussed, or if issues raised earlier on have now been fixed.
How secure is Zorin 17.3 on a fresh install?
Beyond practicing 'safe downloading', what additional tools, security apps, trustworthy information sources do you recommend or use?
What does the average not-so-technical user need to be aware of?
I am running 17.3 Pro, but I chose minimal install so as to choose what software I wanted, along with .debs from other software publishers.
I have the basic built-in firewall, set at default, nothing else.
Is there room to pin a post to the top of this thread on basic steps to enhance security (if deemed necessary on a fresh install)?
Thank you!
Zorin comes with AppArmor:
I've always covered essential security apps in the Unofficial Manual;
rkhunter
chkrootkit
ClamTK
The latter is best used for scanning email and to disable PUA as it never worked correctly in the Windows version either.
In terms of email, you have a choice of:
bogofilter
SpamAssassin
So long as you keep your system updated with security updates as they come through you should be fine, and to make sure of this ensure your downloads are from Main Server not United Kingdom server (for users outside UK don't use your country server as the source for updates either, use Main Server) as it takes time for them to receive the updates.
1 Like