flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > Why we should always disable JS (and flash)

Goto page Previous  1, 2, 3 ... , 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 7253
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699

maybe, i was thinking there are probably too many others kinds, or accidental backdoors bugs inside browsers that don't really need javascript to get triggered. Laughing i believe they will find one soon, maybe they already have, a visit to website with only jgp, jpeg, gif, wav, mp3 is already more than enough to trigger something,
Post 06 Jan 2018, 08:06
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3467
Location: Bulgaria

Post 12 Jan 2018, 13:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space


JohnFound wrote:
Revolution, you will like this article: Let’s Kill JavaScript (and Replace It with Something Better).

It looks promising. But I still think the last part ("Replace It with Something Better") is not needed. At least it would be a improvement over the current situation.
Post 12 Jan 2018, 14:31
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1156

The guy says JavaScript is bad because it's an imperative language instead of declarative. On the contrary, that's what makes it better, and why it's probably so ubiquitous even with all its nasty problems.

Because declarative programming sucks.
Post 12 Jan 2018, 14:50
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space


Furs wrote:
The guy says JavaScript is bad because it's an imperative language instead of declarative. On the contrary, that's what makes it better, and why it's probably so ubiquitous even with all its nasty problems.

Because declarative programming sucks.

Maybe that is the point. Make writing code for browsers sucky and then only when it is truly necessary* will people bother to write it.

* i.e. never
Post 12 Jan 2018, 15:08
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

Okay, so you have finally decided that you will audit every line of JS on a website and only then if you are happy that it doesn't have any of the myriad of problems listed above in this thread, and other as yet undiscovered problems, do you decide it is safe to run it. Of course this would take weeks or months of analysis for just one of those "modern" pages that uses all the latest frameworks and technologies just to display a simple image. But nevermind, you have decided it is worth the effort because the website is important to you. And also you assume that the code won't change during the time it takes you to do the audit.

But then you discover this page:
Can (a ==1 && a== 2 && a==3) ever evaluate to true?
And you realise your analysis is impossible to do correctly without going completely insane.
Post 23 Jan 2018, 05:39
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space


revolution wrote:
Mozilla Confirms Web-Based Execution Vector for Meltdown and Spectre Attacks

https://www.bleepingcomputer.com/news/security/mozilla-confirms-web-based-execution-vector-for-meltdown-and-spectre-attacks/

I guess this is expected. JS can do anything, and that includes stealing your information.

Some technical details about the Spectre attack in JS from here.

Quote:
4.3 Example Implementation in JavaScript

As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). The portion of the JavaScript code used to perform the leakage is as follows, where the constant TABLE1 STRIDE = 4096 and TABLE1 BYTES = 2^25:

On branch-predictor mistraining passes, index is set (via bit operations) to an in-range value, then on the final iteration index is set to an out-of-bounds address into simpleByteArray. The variable localJunk is used to ensure that operations are not optimized out, and the “|0” operations act as optimization hints to the JavaScript interpreter that values are integers.

Like other optimized JavaScript engines, V8 performs just-in-time compilation to convert JavaScript into machine language. To obtain the x86 disassembly of the JIT output during development, the command-line tool D8 was used. Manual tweaking of the source code leading up to the snippet above was done to get the value of simpleByteArray.length in local memory (instead of cached in a register or requiring multiple instructions to fetch). See Listing 3 for the resulting disassembly output from D8 (which uses AT&T assembly syntax).

The clflush instruction is not accessible from JavaScript, so cache flushing was performed by reading a series of addresses at 4096-byte intervals out of a large array. Because of the memory and cache configuration on Intel processors, a series of ~2000 such reads (depending on the processor’s cache size) were adequate evict out the data from the processor’s caches for addresses having the same value in address bits 11–6.

The leaked results are conveyed via the cache status of probeTable[n*4096] for n in 0..255, so each attempt begins with a flushing pass consisting of a series of reads made from probeTable[n*4096] using values of n > 256. The cache appears to have several modes for deciding which address to evict, so to encourage a LRU (least-recently-used) mode, two indexes were used where the second trailed the first by several operations. The length parameter (e.g., [ebp-0xe0] in the disassembly) needs to be evicted as well. Although its address is unknown, but there are only 64 possible 64-byte offsets relative to the 4096-byte boundary, so all 64 possibilities were tried to find the one that works.

JavaScript does not provide access to the rdtscp instruction, and Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now(). However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location. This approach yielded a high-resolution timer that provided sufficient resolution.

Listing 2:

Code:
1 if (index < simpleByteArray.length) {
2   index = simpleByteArray[index | 0];
3   index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
4   localJunk ^probeTable[index|0]|0;
5 }

Listing 3:

Code:
1 cmpl r15,[rbp-0xe0]            ;Compare index (r15) against simpleByteArray.length
2 jnc 0x24dd099bb870             ;If index >= length, branch to instruction after movq below
3 REX.W leaq rsi,[r12+rdx*1]     ;Set rsi=r12+rdx=addr of first byte in simpleByteArray
4 movzxbl rsi,[rsi+r15*1]        ;Read byte from address rsi+r15 (= base address+index)
5 shll rsi12                   ;Multiply rsi by 4096 by shifting left 12 bits}\%\
6 andl rsi,0x1ffffff             ;AND reassures JIT that next operation is in-bounds
7 movzxbl rsi,[rsi+r8*1]         ;Read from probeTable
8 xorl rsi,rdi                   ;XOR the read result onto localJunk
9 REX.W movq rdi,rsi             ;Copy localJunk into rdi

Post 26 Jan 2018, 14:10
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

The browser makers tell us JS is secure so there is nothing to worry about.

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Quote:
I’m now getting about 120,000 downloads a month, and I’m proud to announce, my nasty code is executing daily on thousands of sites, including a handful of Alexa-top-1000 sites, sending me torrents of usernames, passwords and credit card details.

No JS means no stealing your CC numbers etc.
Post 02 Feb 2018, 19:12
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

The gift that keeps on giving. Un-aduitable JS code strikes again.

https://www.bleepingcomputer.com/news/security/iota-cryptocurrency-users-lose-4-million-in-clever-phishing-attack/

Quote:
Since most cryptocurrency users are suspicious of random sites, the hacker linked the iotaseed.io website to a GitHub repository, alleging the website was running the very same code.

In reality, it was not so. An analysis published over the weekend by Alex Studer reveals the hacker ran mostly the same code from the GitHub repository but made clever modifications to the Notifier.js library, which loaded additional code.

The hacker altered the random generator function to give predictable results. Then the hacker logs all the keys generated by the malicious JS code. Waits 6 months, then cashes in.
Post 03 Feb 2018, 06:18
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1156

That last one is not a JS problem though. I mean, this kind of thing (seed generation) wouldn't even be possible without JS in the first place (on a website).

He could have just distributed binaries with the predictable seed, and "legit" source code on GitHub, knowing 99.9% of people will simply download the binary, for the same thing.

Since the seed is just a random string of characters (it doesn't have some "valid" check like a key does), I find it laughable people look for a "seed generator" instead of just randomly generate it themselves. But well, there's plenty of plebs in the world.
Post 03 Feb 2018, 13:23
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

It shows the kinds of problems people have with JS. They trust it because the browser makers say it is secure. And auditing it is impossible because it is not a fixed entity. Some people could download one version and others another booby-trapped version. Or one day it is fine and the next it is malicious. Plus turning it off requires typing a magic unlock phrase into the URL bar and accepting a scary warning etc.

If it was an independent program then the firewall would quickly show that it tried sending data to somewhere and it gets quickly found out. But within a browser JS sending out data is indistinguishable from a million other websites doing all sorts of the same stuff to show the user grumpy cats and whatever.
Post 03 Feb 2018, 13:38
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1156

Yeah but in this case the JS itself is secure. There is no exploit or vulnerability or something that "wasn't intended". It just doesn't do what it advertises to do, and gives a predictable seed.

Using the strongest sandboxes in 15 nested VMs locked away in a computer with no internet access and wiping the entire storage after you're done etc, wouldn't help here, even doing it offline obviously.

I mean it's like a password generator creating passwords like '1234', it's not that the code itself is malicious, it's just stupidly weak or predictable on purpose (and of course the designer took advantage of it).
Post 03 Feb 2018, 13:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

The code is public on github. So you audit that and give it the okay. But the JS you get delivered is not auditable by its very nature, so you don't know what it is doing. If you downloaded the code and compiled it yourself then nothing bad happens. It is only when the delivery is through your "secure" browser that you get pwned.

People are trained to believe JS is perfectly fine. And people that don't believe it get belittled for being paranoid. Many website designers also like to force everyone to have JS because "you can trust it" and you should stop being paranoid.

When I saw that LastPass was using JS to encrypt all your super-secret passwords I knew that it was a huge potential backdoor. The code has been audited many times and comes back as "okay". But what people get delivered can be changed very easily. The site could get hacked. An employee could weaponise it. The NSA/GCHQ/MOSSAD could MITM it. A small change could make a unintentional problem. etc. And no one would know because it is "trusted" so they blindly execute it.

If you had no JS then you cannot be pwned by this hack.
Post 03 Feb 2018, 14:03
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1156

But it can't even work without JS...? Would you rather have the site give out a server-side generated seed in pure html which would work even with JS disabled? That's even less secure, lol.
Post 03 Feb 2018, 15:11
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

It doesn't need to be server side or client side at all. Perhaps that is the real problem. It shouldn't be in the browser to begin with. And it definitely shouldn't be running untrusted/unverified code to create secrets. But people are taught to trust their "secure" and "safe" browser so of course everything will be fine.
Post 03 Feb 2018, 15:24
View user's profile Send private message Visit poster's website Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 813
Location: Jakarta, Indonesia

Imagine you were a lead dev/manager at a software development company.
Would you tell your developers to:
1. Ditch JS completely (this mean only HTML & CSS are allowed on front end side).
2. Use JS sparringly. Adopt graceful degradation/progressive enhancement strategy.
3. ....... [feel free to add you own]

Smile
Post 03 Feb 2018, 17:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space

https://www.theregister.co.uk/2017/09/25/showtime_hit_with_coinmining_script/

Quote:
The websites of US telly giant CBS's Showtime contained JavaScript that secretly commandeered viewers' web browsers over the weekend to mine cryptocurrency.


Quote:
The code was poorly configured – web admins are allowed to set the hashing rate – and resulted in people's machines slowing to a crawl, sparking complaints.

It's not your machine. Let someone else take control of it and do whatever they want with it. Smile
Post 06 Feb 2018, 15:32
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7253
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699

btw, they could use javascript to keylogs different open tabs now, at least, all the add-ons can keylog you,

and if those add-ons are hacked, tempered, good luck i guess, all your passwords belong to us,
Post 08 Feb 2018, 19:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15806
Location: Misner space


sleepsleep wrote:
btw, they could use javascript to keylogs different open tabs now, at least, all the add-ons can keylog you,

and if those add-ons are hacked, tempered, good luck i guess, all your passwords belong to us,

Add-ons are different in that you can audit them before installing. As long as you disable auto-updating, and manually update when it suits you to do another audit, then you should be okay.
Post 09 Feb 2018, 10:28
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1156

Do you really audit addons when you install them? Rolling Eyes I mean, I don't really have the time for that. Confused I just assume most stuff is insecure by default, with exceptions.

Deny by default and all that.
Post 10 Feb 2018, 13:46
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3 ... , 9, 10, 11  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2018, Tomasz Grysztar.
Powered by rwasa.