Hoe is deze ontdekt en is het mogelijk om te zien of deze in het verleden misbruikt is?

Er is vandaag 13 maart een nieuwe update verschenen.

Ja, die indruk wekken ze met hun beschrijving, maar volgens mij klopt dit niet helemaal.
(of anders zou het niet mogelijk zijn om deze post te verzenden, want op www.security.nl is hiervoor javascript nodig....)

In de stand "safest" staat in about:config de parameter "javascript.enabled" namelijk nog steeds op true...
Dus het staat aan.
Vermoedelijk is slechts bepaalde functionaliteit van javascript disabled, maar niet alle javascript.

Het zou niet verkeerd zijn dat het security.nl -team de Torbrowser-bouwers hierover nader aan de tand voelt
en dan de juiste informatie hierover op deze site te geven.

Vanwege dit soort mogelijke fatale fouten met JavaScript functies draai ik de Tor Browser onder Linux altijd binnen een AppArmor profiel. De virtualisatie opties van de CPU cores staan onder de BIOS/UEFI settings ook uit.

https://github.com/micahflee/torbrowser-launcher

Onder alle omstandigheden is het dus nodig om anomalieën in code, die in aanleg verdacht zijn via procedures, die gebruikt worden bij verdachte activiteit, te ontdekken. Dit kan door gericht werken met reguliere expressies, bijvoorbeeld en zoeken naar code conversies.

Steeds weer blijkt dus het blokkeren van het aflopen van zeker JavaScript de enige juiste beveiligingsmethode te zijn,
zowel voor bij bestaande kwetsbaarheden en tevens ook werkend tegen kwetsbaarheden, die nog niet eens bestaan.

NoScript en uMatrix zijn dan ook binnen gewone browsers de enige manieren om je afdoende te kunnen beschermen.

Normaliter gaat het daarbij altijd om een afweging maken tussen het toelaten van de minimale functionaliteit,
die nodig is om een webpagina voldoende te laten werken en het maximale dat geblokkeerd moet worden
om niet kwetsbaar te zijn.

Daar is echt geen rakettechnolgie voor nodig en zou eigenlijk alle browsergebruikers moeten worden geleerd.

Daarnaast is het dus belangrijk dat onveilige websites (kwaadaardige, mogelijk kwaadaardige,
PHISH-ende en scammende en spammende websites geheel worden geblokkeerd.

Daarnaast moet javascript helemaal worden geblokkeerd bij websites,
waarvan we nog niet weten, dat ze een risico kunnen vormen.
Want malware kan slechts enkele uren actief zijn.

Daarom nieuwe bestemmingen in de browser nooit rechtstreeks bezoeken,
maar je eerst op de hoogte stellen of je ze veilig kunt bezoeken.
"Curiosity killed the cat" in dit geval. Ofwel een gewaarschuwd "bladeraar" telt voor twee
of in het Engels "forewarned means forearmed".

Javascript, in de vorige eeuw ontworpen door Brendan Eich in luttel tien dagen tijd,
is en blijft de royale weg naar binnen voor allerlei malscript en de gevolgen ervan.

Test en kijk derhalve hoe lang javascript langer afloopt dan normaal te verwachten.
Is dit het geval van excessieve runtime moet er in de code worden rondgespit
tot we weten waar dit aan kan liggen.

DOM-XSS scanning laat een heleboel aan sinks en sources zien,
waarvan niet meteen bekend is wat kan worden uitgebuit door aanvallers en wat niet -
bijvoorbeeld 3rd party $.get() auto-executes if content type = text/JavaScript .
Ook kan de browser in zulke gevallen gaan weigeren te reageren.

Trouwens verlaten en niet meer bijgehouden of verouderde code gebruiken is een groot risico nemen.
Beter safe dan sorry achteraf. Daarom houdt het script-blokkeer-vizier omlaag als dat nodig is.

luntrus

Het is bekend dat Javascript altijd aan staat in ToR browser. De reden is dat heel veel sites niet meer functioneren als er geen Javascript mag worden uitgevoerd. Wil je dus echt anoniem zijn dan moet je dat zelf even uit zetten met iets als noscript. Met Javascript is het mogelijk om gebruikers van een website te ontmaskeren door hun echte IP adres te versturen.

Bedankt voor deze bevestiging. Je ondersteunt dus mijn feitelijke boodschap.
Namelijk dat het niet klopt wat de redactie in het artikel beweerde, namelijk dat in de stand "Safest" javascript uitgeschakeld zou zijn.
Dus redactie: trek het a.u.b. nog maar eens even na, en spreek de waarheid.

Velen hebben nu volop tijd om te testen, te linten en te fuzen:
https://webtoolkitonline.com/Niet alleen maar een nuttige maar tevens een leerzame bezigheid voor JavaScript security bevlogenenen alle andere belangstellenden. Voorbeeldje van een door een vulnerability extension geladen content.js scriptje via Ctrl+Shift+I (de browser console dus). Daar gaan we dan. Na de alert volgt:
Javascript Tester online: https://webtoolkitonline.com/javascript-tester.html
Tevens: https://codebeautify.org/jsvalidate
via de laatste tool ->

Validation of a simple vulners script against regexp->
Het blijft een hele opgave, maar is wel zeer leerzaam op de lange termijn om te doen.
Je gaat namelijk bepaalde patronen en overeenkomstigheden ontwaren op de langere tot middellange termijn.

Net als de spoorzoeker, die aan de aanwezigheid van plantago major bijv. zag
dat er westerlingen in de buurt waren geweest.
You learn to hear the JavaScript grass grow with your ear stuck (stack?) firmly to the ground. ( } >;).

Groetjes aan iedereen hier, alsmede een goede en vooral gezonde week voor u allemaal,

luntrus

O, ik zie net dat zdnet er een artikel over heeft geschreven:
https://www.zdnet.com/article/tor-team-warns-of-tor-browser-bug-that-runs-javascript-on-sites-it-shouldnt/

Mogelijk verklaart dit dat ik soms een "suspected traffic" melding van Google krijg.
Een nieuw Tor circuit kiezen helpt niet.
Browser afsluiten en opnieuw opstarten wel.

Dit wekt de indruk dat er javascript in je browser is geïnjecteerd die actief blijft als je naar een andere site gaat.
(zelfs na het kiezen van een nieuwe identiteit).

Beware!

Bij nader inzien klopt het volgens mij toch wel redelijk goed hoor.
Wat men echter niet moet vergeten is dat de security-slider in TorBrowser samenwerkt met NoScript
waar TorBrowser standaard mee komt. (en in about:config: extensions.torbutton.noscript_inited = true)

Zet je de slider in stand "Safest" dan geldt de default stand van NoScript om géén javascript uit te voeren.
Hierbij staat "javascript.enabled" in Firefox weliswaar op "true", maar NoScript zorgt ervoor dat geen javascript wordt uitgevoerd. Je kan dit per site overrulen door in NoScript aan te geven dat er wél javascript is toegestaan.

Verder zullen in de stand "Safer" een aantal javascript opties worden uitgeschakeld:
javascript.options.asmjs = false
javascript.options.baselinejit = false
javascript.options.ion = false
javascript.options.native_regexp = false
En verder mathml.disabled=true (= capaciteit om wiskundige formules weer te geven uitgeschakeld)
en het font-grelateerde gfx.font_rendering.opentype_svg.enabled = false

In de stand "Safest" komt hier het graphics gerelateerde svg.disabled = false nog bij.

Verder geeft extensions.torbutton.security_slider met een getal steeds de stand van de slider weer. (4, 2 of 1)

Het enige wat verwarring zaait is de uitleg-tekst bij de TorBrowser Slider. https://tb-manual.torproject.org/security-settings/
Hier staat namelijk keihard dat in de stand "Safest" default in het geheel geen javascript zal worden uitgevoerd, punt.
Maar er hoort dus te staan dat dit afhankelijk is van de instellingen die je maakt in NoScript,
en dat NoScript default javascript zal blokkeren.
En verder dat de functionaliteit van javascript maar beperkt is als je het in NoScript aan zou zetten voor bepaalde site(s) in geval de security-slider staat in stand "Safer" of "Safest"

Storm in een glas water dus. Eigenlijk niets aan de hand.:
As far as I can see there is no problem with the security slider in Tor Browser 9.0.6

(maar wel nuttig dat we weer eens even stilstaan bij de potentiële gevaren van javascript)

Of het om het hier genoemde probleem gaat weet ik niet zeker, maar wellicht toch goed om even te noemen:

Er is een nieuwe versie van NoScript (V.11.0.17)
(TB 9.0.6 komt standaard met NoScript versie V.11.0.15)

In de changelog van V.11.0.17 staat:

Dus ergens is blijkbaar wel "iets" mis in TB 9.0.6 (die gebruik maakt van firefox ESR)
i.c.m. NoScript met betrekking tot Content Security Policy, hetgeen kan worden opgelost met de nieuwe NoScript versie!

We moeten ook vaststellen dat veel website inrichters verkeerd omgaan met Content Security Policy best policies. Er gaat heel veel fout of blijft onder de maat. Daarom heeft no script er mogelijk ook problemen mee. Dat ondergraaft de veiligheid van verbindingen. Het vraagt om er meer oog voor te hebben en om validatie.
luntrus

Dat komt ook omdat CSP nog niet helemaal is uitgekristalliseerd en de ene browser de andere niet is.
We zitten inmiddels bij CSP level 3 dacht ik.

Leerzaam is bijv. https://content-security-policy.com/ met een browsertest op
https://content-security-policy.com/browser-test/
Het leuke van die test is dat het plaatje gewoon laadt zonder javascript. Dus geen grijze box zoals het hoort.
Blijkbaar moet javascript aan om CSP goed te kunnen verzorgen.
Bij wijze van spreken: wil je niet door de hond gebeten worden, dan zul je een bijtende kat in huis moeten nemen...
Tja...

Daar zat inderdaad het probleem.

Hetzelfde wordt inmiddels ook vermeld op https://blog.torproject.org/new-release-tor-browser-906:

>>Bij de lancering van de nieuwste Tor Browser, versie 9.0.6, meldt het Tor Project dat er een bug in de browser zit die het uitvoeren van JavaScript op het hoogste beveiligingsniveau mogelijk maakt. Er wordt aan een oplossing gewerkt.
>>

Exact dezelfde fout zit nu dus in Tor 10.