flat assembler
> Heap > Why we should always disable JS (and flash)Goto page Previous 1, 2, 3 ... 12, 13, 14, 15, 16, 17 Next |
| Author |
|
|
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, |
|||
14 Sep 2018, 14:48 |
|
|
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, |
|||
|
14 Sep 2018, 15:31 |
|
|
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? |
|||
|
14 Sep 2018, 16:38 |
|
|
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.
|
|||
|
14 Sep 2018, 23:14 |
|
|
sorry, i dont get it,
|
|||
|
15 Sep 2018, 02:49 |
|
|
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 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. |
|||
|
15 Sep 2018, 10:27 |
|
|
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, |
|||
|
15 Sep 2018, 13:37 |
|
|
15 Sep 2018, 16:52 |
|
|
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, |
|||
|
16 Sep 2018, 15:39 |
|
|
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. |
|||
|
16 Sep 2018, 16:39 |
|
|
sleepsleep wrote: A new CSS-based web attack will crash and restart your iPhone |
|||
|
16 Sep 2018, 17:16 |
|
|
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. |
|||
|
16 Sep 2018, 17:36 |
|
|
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. |
|||
|
17 Sep 2018, 01:00 |
|
|
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. |
|||
|
17 Sep 2018, 07:29 |
|
|
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. 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. 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. |
|||
|
17 Sep 2018, 07:42 |
|
|
revolution wrote:
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,  |
|||
|
17 Sep 2018, 08:00 |
|
|
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 |
|||
|
17 Sep 2018, 10:43 |
|
|
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 
probably should remind them not to include JS this time,  |
|||
|
17 Sep 2018, 22:10 |
|
|
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,
|
|||
|
18 Sep 2018, 11:26 |
|
|
So once again a site is hacked and has rogue JS code inserted to clickjack you CC details. You can't fix this by "improving" the JS parser because this is precisely what JS is supposed to do; i.e. run arbitrary code delivered to you from random websites.
https://thehackernews.com/2018/09/newegg-credit-card-hack.html Quote: Magecart hackers used what researchers called a digital credit card skimmer wherein they inserted a few lines of malicious Javascript code into the checkout page of Newegg website that captured payment information of customers making purchasing on the site and then send it to a remote server. |
|||
|
24 Sep 2018, 04:53 |
|
| Goto page Previous 1, 2, 3 ... 12, 13, 14, 15, 16, 17 Next < Last Thread | Next Thread > |
Forum Rules:
|