back to article Three words you do not want to hear regarding a 'secure browser' called SafePay... Remote. Code. Execution

Folks running Bitdefender's Total Security 2020 package should check they have the latest version installed following the disclosure of a remote code execution bug. Wladimir Palant, cofounder of Adblock-Plus-maker Eyeo, tipped off Bitdefender about the flaw, CVE-2020-8102, after discovering what he called "seemingly small …

  1. Pascal Monett Silver badge

    And that's how Marketing gets bitten

    Bitdefender Total Security 2020 is not totally secure. Ironic.

    Of course, from a marketing point of view, you couldn't call it Bitdefender Best Security Effort 2020. You are either Total, or you don't even exist.

    Well, at least they corrected the problem when notified, not like some others on the market, eh, IBM ?

    1. Stuart Castle Silver badge

      Re: And that's how Marketing gets bitten

      Anyone who knows a fair bit about computer security knows that total security is almost impossible to achieve. Every security system has flaws, but to counter balance that, some flaws require a talented hacker to exploit. Thankfully, the chances are most users won't encounter a really talented hacker.

      1. vtcodger Silver badge

        Re: And that's how Marketing gets bitten

        Perhaps I misunderstand, but in this case, I think all that is necessary is for you to visit a website crafted by a really talented hacker. The website can promise to regrow hair, smooth out wrinkles, serve up free world class porn, earn you money at seven times the prime rate or to grant you eternal youth. It doesn't have to deliver any of those things.

  2. Mike 137 Silver badge

    Yet again ... yawn ...

    '"Occasionally their product will have to modify the server response, for example on search pages where they inject the script implementing the Safe Search functionality," Palant explained.'

    When will it finally sink in that client side scripting should never be used for security. Client side scripting is the primary vector for automatic client compromises, so it's the exact opposite of the right approach. If you want a secure browser, design one from the ground up in native code (or if you really must, an interpreted language like Java). That doesn't of course ensure it's not vulnerable, but it should be obvious that any code that sits within a web page is open to malicious tampering.

    1. vtcodger Silver badge

      Re: Yet again ... yawn ...

      I agree that downloading code from some dude's server in God knows where, then executing that code is utterly incompatible with user security. Three problems however

      1. Some useful services like interactive maps currently can't work without scripting. Interactive map, etc APIs would have to be defined and implemented in browsers before scripting can be killed.

      2. There is perhaps some case for scripting of content presentation as opposed to tinkering with operating systems interfaces. Granted, the current results seem generally to be annoying at best. But they are what "customers" (guys who pay directly) as opposed to "consumers" seem to want. Personally I could probably get by in a world where stuff I don't want to see is never arbitrarily superimposed over whatever I'm trying to read based on my mouse position. But maybe everyone else loves that. Anyway, I think that in concept at least, presentation scripting could be implemented with few or no security issues.

      3. Advertisers love scripting. Companies like Google will probably try any number of ill conceived schemes to accommodate the guys who pay the bills no matter what the risks to consumers of the product. After all, scripting is not a risk to either Google or the advertisers. Just to the product -- thee and me.

      1. itzumee

        Re: Yet again ... yawn ...

        >>Some useful services like interactive maps currently can't work without scripting. Interactive map, etc

        >>APIs would have to be defined and implemented in browsers before scripting can be killed

        They could be implemented in WebAssembly assuming the browser provides support

        1. Glen 1

          Re: Yet again ... yawn ...

          "They could be implemented in WebAssembly"

          *Any* code that can modify what the viewer sees can be abused.

          The biggest problem is *3rd party* code. You can turn it off with noscript etc, but many sites have their assets across multiple domains, That's *before* we start talking about advertisers.

          Go to a random site on the internet, without using dev tools, you have no way of knowing where what you are seeing is coming from. Not just remote (3rd party) origins for files, but XSS and Iframes. The domain you type in/click on is just the first link in a chain. IMHO, It shouldn't be.

          Most sane mail clients learnt the lesson of not loading remote content from an unvetted source without express permission. The web would be a safer place if web browsers did the same.

          Firefox's container tabs are a good start.

  3. This post has been deleted by its author

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like