flat assembler
Message board for the users of flat assembler.

flat assembler > Heap > Why we should always disable JS (and flash)

Goto page Previous  1, 2, 3 ... 11, 12, 13
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
imo, the issue is not about JS but on limiting the scripting language power,

revolution wrote:
This is very different from JS that is supposed to run random code as dictated by the site.

then, browser should takes away this feature, or allow us to off this feature,

i think the dynamic update feature through scripting language is useful and essential in 2018, there is no way one would refresh every few second to get the latest information,
Post 14 Sep 2018, 14:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15974
Location: Qo'noS
sleepsleep wrote:
ii think the dynamic update feature through scripting language is useful and essential in 2018, there is no way one would refresh every few second to get the latest information,
If you allow it the privilege of connecting to remote servers to update the things you want to see, then you also necessarily allow it to connect to remote servers and do the things you don't want. You can't selectively allow one without also allowing the other.
Post 14 Sep 2018, 15:31
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
i think we need to clarify what is third-parties here,

a.microsoft.com
socket.microsoft.com
msdn.microsoft.com
i guess all these not third-parties when you access microsoft.com

we probably dont want access embedded to fb.com fsdn.facebook.com when we get microsoft.com,

but what if the login feature allow user to login through their fb account to enjoy the download in microsoft.com? or view videos etc, those stuffs are embedded inside the original site, microsoft.com

in noscript, we could disable access to fb and fsdn, but there is no way to punish microsoft for embedding such codes,

but what if fb codes is integrated into microsoft.com and they become essential to function as a service? still count them as third-party?

the blockchain would punish the domain when they include unnecessary or when there is flaw such and such domains are used for tracking purpose and serve no other useful purpose,

since domain need to stack some crypto, those crypto would then pay to user who use this blockchain browser, it could works by entice users to allow tracking and thus get some crypto, at least you get something after you let go something,

or 0 crypto when you choose to not allowing unnecessary third-parties,

i need more clarity on what constitute as third-parties?
Post 14 Sep 2018, 16:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15974
Location: Qo'noS
When I mentioned third party, I meant any system that is not your own. So basically all websites, including your own websites hosted by others.
Post 14 Sep 2018, 23:14
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
sorry, i dont get it,
Post 15 Sep 2018, 02:49
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
revolution wrote:
Browser errors can be fixed, and sites can't rely upon them existing in all browsers. This is very different from JS that is supposed to run random code as dictated by the site.

Just because browsers can have bugs doesn't mean we should give up and throw our hands in the air and let JS do anything it wants to. We can significant;y reduce the problem space by simply not allowing JS at all.

Just like we can reduce the problem space by simply not allowing HTML. If a scripting language has strictly defined security boundary, its attack surface is by no means larger than for any declarative language.
Post 15 Sep 2018, 10:27
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
from what i understood, these technologies, html, css, javascript, vbscript, etc, they are extension to what our os functions, and obviously we can't allow such extension to include all our os functions, but in another perspective, what actually difference them?

we could transfer any bits from a to b, unless transport protocol is having issue, otherwise we wouldn't have issues in transferring bits, just like shipping industries,

next is sending all these contena to their respective owners,

distribution should causes less and less authority,
Post 15 Sep 2018, 13:37
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
Post 15 Sep 2018, 16:52
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
A new CSS-based web attack will crash and restart your iPhone
https://techcrunch.com/2018/09/15/a-new-css-based-web-attack-will-crash-and-restart-your-iphone/

i think the issue is more on what we do with the data transmitted to us, how we open those packets, how we analyze those packets, stream bytes, how we process those bytes, this is more than JS alone, it includes every bytes, from network to us,
Post 16 Sep 2018, 15:39
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15974
Location: Qo'noS
Well, bugs will be present in your systems. But the thing to realise from this thread is that most of the things I have posted do not rely upon bugs in the implementation. Since such bugs would be fixed eventually things would improve as time progresses. But the difference here is that JS in its fundamental design is the problem, not any specific implementation of it. If it was only a bugs in the implementation then we could fix them and move on.

You can't "fix" JS by simply eliminating bugs in the implementations. A perfectly bug free implementation of JS will still make you vulnerable to most of the problems as posted in this thread.
Post 16 Sep 2018, 16:39
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1225
sleepsleep wrote:
A new CSS-based web attack will crash and restart your iPhone
https://techcrunch.com/2018/09/15/a-new-css-based-web-attack-will-crash-and-restart-your-iphone/
Just Apple code quality.
Post 16 Sep 2018, 17:16
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
revolution wrote:
You can't "fix" JS by simply eliminating bugs in the implementations. A perfectly bug free implementation of JS will still make you vulnerable to most of the problems as posted in this thread.

Nothing new here. If someone is able to cross security boundary with JS only and without requiring bugs in the implementation, then, well, it’s a bug in specifications (some corner case that hasn’t been taken into account when designing the security boundary). Which is more severe since specification bugs occur earlier in the software lifecycle.

Still, I’d insist security vulnerabilities have nothing to do with language paradigms.
Post 16 Sep 2018, 17:36
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: 15974
Location: Qo'noS
Let us look at meltdown, that crosses security boundaries and there are no bugs required in JS for that to happen. The JS was doing what it was supposed to do. Indeed JS implementations were deliberately downgraded in an attempt to ruin the timing measurement accuracy to try to prevent the attack.

The most recent BA posting above doesn't require any bugs in JS. The JS did exactly as it was supposed to, it ran the arbitrary code it was given from the website. Just that the website was delivering rogue code. You can't fix that by making changes to JS. The JS interpreter can't distinguish bad code from good code.
Post 17 Sep 2018, 01:00
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
revolution wrote:
Let us look at meltdown, that crosses security boundaries and there are no bugs required in JS for that to happen. The JS was doing what it was supposed to do. Indeed JS implementations were deliberately downgraded in an attempt to ruin the timing measurement accuracy to try to prevent the attack.

Meltdown is not a JS fault. It’s a fault in lower-level implementation. If having measurable physical side effects can be considered a fault.

revolution wrote:
The most recent BA posting above doesn't require any bugs in JS. The JS did exactly as it was supposed to, it ran the arbitrary code it was given from the website. Just that the website was delivering rogue code. You can't fix that by making changes to JS. The JS interpreter can't distinguish bad code from good code.

Can I have a link to this one? If the JS engine allows code running in it do anything (thus giving it rights equal to its own) then it’s clearly a lack of security boundary which is a bug in either implementation or specification.
Post 17 Sep 2018, 07:29
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: 15974
Location: Qo'noS
DimonSoft wrote:
Meltdown is not a JS fault. It’s a fault in lower-level implementation. If having measurable physical side effects can be considered a fault.
Without JS meltdown is not a problem. JS facilitates the exploitation of the CPU bug. Because that is how JS works. The users browser is running code to exploit their own system. Code that is delivered by unknown random websites. It simply shouldn't be trusted and yet so many people believe they are safe because the vendors say it is.
DimonSoft wrote:
Can I have a link to this one? If the JS engine allows code running in it do anything (thus giving it rights equal to its own) then it’s clearly a lack of security boundary which is a bug in either implementation or specification.
The BA article I posted previously talked about the source website being hacked and JS code sending the users CC and other data to the hacker. Without JS doing the dirty work it wouldn't have worked because after the first few users find they end up on a rogue site it gets stopped quickly. But with JS the data is copied and goes to the real BA server also so everything looks perfectly fine.

It all comes down to unauditable and untrustworthy code being run by users browsers and doing unknown things. It is just too easy to abuse. And it requires the user to trust every website that exists. I can't see how that can ever be a good thing.
Post 17 Sep 2018, 07:42
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
revolution wrote:

Without JS meltdown is not a problem.

meltdown is always a problem in the way processor processes or handle things, even without JS (since JS probably the easier way to jack this bug up) hacker could still use skype call, youtube video, midi audio, etc, anything that read from internet to modify environment into causing the bug,

the weakest link, JS, no doubt, Laughing
Post 17 Sep 2018, 08:00
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
revolution wrote:
Without JS meltdown is not a problem.

If people didn’t need air to breathe, lack of air in space wouldn’t be a problem. Let’s get rid of people.

revolution wrote:
JS facilitates the exploitation of the CPU bug. Because that is how JS works. The users browser is running code to exploit their own system.

Remove JS and download random desktop software instead of it. Nice solution, but now you have a bigger problem.

revolution wrote:
Code that is delivered by unknown random websites. It simply shouldn't be trusted

Which is a requirement that should be put somewhere in the specification of JS engine. Oh, wait!.. It is an implied requirement for any software.

revolution wrote:
and yet so many people believe they are safe because the vendors say it is.

As soon as JS engine is implemented correctly, they are safe. No software is implemented correctly so you’re never safe no matter your world is JSy or not.

Meltdown is not a vulnerability, it is yet another means to exploit the way our world works. Much trickier than social engineering though, but gives more style points if you succeed.

revolution wrote:
The BA article I posted previously talked about the source website being hacked and JS code sending the users CC and other data to the hacker. Without JS doing the dirty work it wouldn't have worked because after the first few users find they end up on a rogue site it gets stopped quickly. But with JS the data is copied and goes to the real BA server also so everything looks perfectly fine.

Hack the website you download some desktop software from and replace the installer with a rogue one. It’s all code, no need to make JS a special case. You either trust the source or don’t. If the trusted source is hacked, you lose, if not—you win. Remember the Ken Thompson hack: you NEED to trust somebody.

revolution wrote:
It all comes down to unauditable and untrustworthy code being run by users browsers and doing unknown things.

Browser JavaScript is quite limited in its capabilities. You have to trust the implementation to deny any rogue JS code. Just like you have to trust it to deny rogue HTML and CSS. Just like you should trust your OS to deny software and drivers that are not properly signed. Or at least to limit their capabilities to a perfectly valid subset. JS is by no means different from any other software here.


Last edited by DimonSoft on 18 Sep 2018, 05:46; edited 1 time in total
Post 17 Sep 2018, 10:43
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
David Patterson Says It’s Time for New Computer Architectures and Software Languages

https://spectrum.ieee.org/view-from-the-valley/computing/hardware/david-patterson-says-its-time-for-new-computer-architectures-and-software-languages

from scratch Smile
probably should remind them not to include JS this time, Razz
Post 17 Sep 2018, 22:10
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7502
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
tried react native node nodejs, it seems that this JS thing concept here is dangerous, because PATH is set to nodejs, and Powershell, i would say insane, but this is recommended steps,
Post 18 Sep 2018, 11:26
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 ... 11, 12, 13

< 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


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.