Hans Jerry Illikainen discovered a type conversion vulnerability in the MP4 demuxer of the VLC media player, which could result in the execution of arbitrary code if a malformed media file is played.
This update upgrades VLC in stretch to the new 3.x release series (as security fixes couldn’t be sensibly backported to the 2.x series). In addition two packages needed to be rebuild to ensure compatibility with VLC 3; phonon-backend-vlc (0.9.0-2+deb9u1) and goldencheetah (4.0.0~DEV1607-2+deb9u1).
VLC in jessie cannot be migrated to version 3 due to incompatible library changes with reverse dependencies and is thus now declared end-of-life for jessie. We recommend to upgrade to stretch or pick a different media player if that’s not an option.
Warning required for VLC users in Whonix 13 (Jessie)?
For now the wiki should point to this Qubes doc chapter. The claims that are made in our version should be verified ( i.e can use custom firewall rule-sets). Its always possible that I missed something and although custom rules cannot be used with Whonix, they can be used with other VMs.This could make the system vulnerable and is not a chance that should be taken when there is an option that has already passed review. No custom rule-sets but a second non-DispVM firewall-VM can be used. Lets give marmarek whatever time he needs to ensure these instructions are sound.
The edits will be ready for your review later today
Symmetric Keys A older method of encryption. One key is used for both
encryption and decryption.
Older implies obsolete? Luks encryption is symmetric. And it works well.
Not outdated / obsolete at all. Symmetric encryption even won’t fall
short against Post-Quantum Cryptography (PQCrypto). So when practical
(not very much when communicating with people you can’t meet in person),
I would even prefer symmetric encryption.
The latter sentence worth pointing out in the wiki? @HulaHoop
Verifiable builds. Not currently possible for Whonix I understand. If so, this part needs to change “Some readers might be curious why Whonix is verifiable…” (Whonix is also marked in Red in the table as a “no” for verifiable).
The onion link to Tor signing keys is wrong (doesn’t resolve). Does anyone know where signing keys are on the Tor Project .onion these days i.e. tor.xxxxxxxxx.onion/signingkeys?
No problem 0brand - multiple fix-ups are the norm.
One thing you did cut from the edits was the number of bits of info related to exposure of 1, 2 or 3 guards. I think that is still useful to footnote somewhere. Maybe even the fingerprinting or data collection page.
I’ll replace the footnote in entry guards chapter.
Additional fingerprinting content was added to “Tor entry guards”. Maybe add some of that content under a new “Entry Guards” subheading in “fingerprinting” and “Data Collection” chapters.
An old attack was observed in the wild that exploited a JavaScript vulnerability in Firefox. [11] The observed version of the attack collected the hostname and MAC address of the victims’ computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a security slider in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings.
The real Q is would it have leaked the MAC address and hostname if successfully run in Whonix-Workstation? I gather not for MAC address, yes for generic Whonix-WS hostname, but that needs to be explicitly clarified I think.
Another nit, spacing on the templates that were edited. After bullet points or mboxes, an extra carriage return is usually required so it doesn’t look bunched up.
@Patrick this Whonix History page on the main ToC is severely outdated i.e. doesn’t show versions beyond 0.4.5.
Since we are nearly at Whonix 14, I think this should be removed from the main ToC, and simply sit in a link somewhere stating “Users can read more about the early history of Whonix here.”
Either that, or insert descriptions for > 0.4.5 → Whonix 13. Which seems a lot of work for very little benefit.
Another option, we just keep the top “history” section, and put all the version info in a separate “Whonix Version” wiki page, since it is ancient and almost nobody will care / read it anyhow.
Delete all the stuff related to TorVM in the wiki page; or
Send all that info to a deprecated page for posterity, since it’s not a fair comparison if the project is dead. Then I would footnote: “QubesOS TorVM was previously part of this comparison, but it has been deprecated. Interested readers can refer to the historical comparison here [embedded link].”
While clean-up & dusting out the Whonix attic is on the cards:
1. The entire page of Dev/Old Changelog should be moved back to the dev backroom where it belongs and moved out of the Whonix Overview section IMO.
It is strictly dev interest only, old and out-of-date for recent developments, badly needs editing, and is probably only read very occasionally.
A leaner, focused ToC page increases readibility and reduces overall complaints e.g. as noticed with various forum topics decreasing in frequency as documentation became clearer or was created to fill a void.
2. There is also a need to manage the size of documentation “chunks” in the most extreme cases. Right now, some of those Tor pages could easily be collapsed into a single page, while the Security etc pages could have a entire section of their own on the main TOC.
The Security Guide in particular has a logical structure to break down into 5 or 6 chunks (pages) e.g. security by platform/VM (host, Whonix-WS, Whonix-GW, Qubes-Whonix) and a couple of other miscellaneous bits (operating system / software package updates, repositories, etc.) that would nicely round out a section on the main TOC, called “Basic Security Guide”.
The same method can be repeated for “Advanced Security Guide”, which is far too long. Now we have a “collapsible” ToC, the impact is negligible, but the improvement will be great.
Working on Libre development for 2 week or so. Unfortunately I’ve been having some creative difficulties. Writers block? I’m close to finishing and normally I would say I’ll have it done latter on today. However, its most likely going to take me a few more days with the way progress is going. As soon as this it finished (all edits are complete and pushed to wiki) I should be able to complete my backlog rather quickly.
