Communicating that unsupported browsers cannot be used

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Communicating that unsupported browsers cannot be used

Ben Bucksch
I'm seeing so many companies using age-old Firefox versions, and I keep
telling them they can't, and I keep talking to walls.

Even Eclipse SWT is still not supporting FF31 and shows no initiative to
move. That means a larger number of downstream products use an insecure
browser. For Eclipse, that's particularly bad: if developers are hacked,
all their users can be hacked, too. See linux kernel breakins etc.

Mozilla needs to do a much better job in communicating that using old
browser is not an option. FF24 doesn't *exist* anymore. Nobody gets that
at the moment.

Some ideas:

  * More aggressive updates
  * Popups that come up when the product is unsupported
    (including link to help page that explains reasons)
  * Marketing communication
    explaining reasons why it's important to update. A simple "please
    update" won't do, neither will "for security reasons". We need to
    picture them, in very colorful language, and giving some horror
    scenarios, what can happen when they don't update: Virii, stolen
    private pictures, targetted attacks at companies, customer data
    protection etc., all their data is free for grabs


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Sean Leonard-6
On 11/17/2014 7:50 AM, Ben Bucksch wrote:

> I'm seeing so many companies using age-old Firefox versions, and I keep
> telling them they can't, and I keep talking to walls.
>
> Even Eclipse SWT is still not supporting FF31 and shows no initiative to
> move. That means a larger number of downstream products use an insecure
> browser. For Eclipse, that's particularly bad: if developers are hacked,
> all their users can be hacked, too. See linux kernel breakins etc.
>
> Mozilla needs to do a much better job in communicating that using old
> browser is not an option. FF24 doesn't *exist* anymore. Nobody gets that
> at the moment.

Except, of course, that FF24 does exist...

Upgrading to new versions costs time and money. Developer time is
especially expensive. If it's so important to Mozilla, Mozilla should
have a fund to pay developers to do the work.

Sending ominous warning messages to users doesn't solve much. Users
aren't the developers who are bundling Firefox in the respective app.
Rather than upgrading the browser (which they can't do), users will stop
using Firefox, and stop using the associated app. Maybe they'll switch
to Chrome or something.

Sean

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Ben Bucksch
In reply to this post by Ben Bucksch
Hi Sean,

your reaction is fairly typical and shows very nicely the depth of the
problem.

Sean Leonard wrote, On 17.11.2014 18:55:
> Except, of course, that FF24 does exist...

It has known critical security holes. That means: Users are highly
likely to get infected and have their personal or professional data
stolen. It cannot be used anymore (by anyone, other than in a
non-Internet lab setup). So, effectively, it doesn't exist anymore.

It would be nice, if browsers were supported longer by Mozilla and Linux
vendors (say 2 years of security updates), but that wouldn't change the
underlying issue of awareness of the problem. This must change entirely,
and this is what I am trying to get at.

> Upgrading to new versions costs time and money. Developer time is
> especially expensive. If it's so important to Mozilla, Mozilla should
> have a fund to pay developers to do the work.

I know that it costs time and money, this is part of my job. It's
something you need to calculate and schedule in when you ship a product
together with a (any!) browser engine.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Rob Stradling
It would be nice if each browser came with a hardcoded, predetermined
date by which the user MUST upgrade to a newer version.  Failure to
upgrade by that date would mean that the browser ceases to function
(except to permit the user to upgrade).

With clear messaging in the UI, would this be an appropriate solution?

On 17/11/14 19:21, Ben Bucksch wrote:

> Hi Sean,
>
> your reaction is fairly typical and shows very nicely the depth of the
> problem.
>
> Sean Leonard wrote, On 17.11.2014 18:55:
>> Except, of course, that FF24 does exist...
>
> It has known critical security holes. That means: Users are highly
> likely to get infected and have their personal or professional data
> stolen. It cannot be used anymore (by anyone, other than in a
> non-Internet lab setup). So, effectively, it doesn't exist anymore.
>
> It would be nice, if browsers were supported longer by Mozilla and Linux
> vendors (say 2 years of security updates), but that wouldn't change the
> underlying issue of awareness of the problem. This must change entirely,
> and this is what I am trying to get at.
>
>> Upgrading to new versions costs time and money. Developer time is
>> especially expensive. If it's so important to Mozilla, Mozilla should
>> have a fund to pay developers to do the work.
>
> I know that it costs time and money, this is part of my job. It's
> something you need to calculate and schedule in when you ship a product
> together with a (any!) browser engine.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Hubert Kario
On Monday 17 November 2014 20:45:02 Rob Stradling wrote:
> It would be nice if each browser came with a hardcoded, predetermined
> date by which the user MUST upgrade to a newer version.  Failure to
> upgrade by that date would mean that the browser ceases to function
> (except to permit the user to upgrade).
>
> With clear messaging in the UI, would this be an appropriate solution?

While I agree that deprecating old security sensitive code would be nice,
I don't think this is something users would welcome in any way.

There would be an outrage.

We never should do anything that will (or can) impact users directly.

--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Chris Hofmann-2
On 11/18/14 8:13 AM, Hubert Kario wrote:

> On Monday 17 November 2014 20:45:02 Rob Stradling wrote:
>> It would be nice if each browser came with a hardcoded, predetermined
>> date by which the user MUST upgrade to a newer version.  Failure to
>> upgrade by that date would mean that the browser ceases to function
>> (except to permit the user to upgrade).
>>
>> With clear messaging in the UI, would this be an appropriate solution?
> While I agree that deprecating old security sensitive code would be nice,
> I don't think this is something users would welcome in any way.
>
> There would be an outrage.
>
> We never should do anything that will (or can) impact users directly.
>

The way to breakdown the fear that users have about upgrades is
to to produce higher quality software, for Firefox, but also across
the industry.   The fear comes from running into serious regressions
that make the software unusable after the upgrade.  The fear is well
grounded.  Think about it.  Has it ever happened to you?

The difference between you and the users we are talking about
is you usually have the skills and understanding to dig yourself
out, or find other options if the upgrade is truly broken.

The fear is compounded for those that don't have these skills.

Make better software, and do a lot more testing before unleashing
upgrades on the world and this problem can be reduced or might
even go away, but it would take much more time and effort
to repair the damage and loss of confidence that has been done.

-chofmann
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Ben Bucksch
In reply to this post by Rob Stradling
Hubert Kario wrote, On 18.11.2014 17:13:

> On Monday 17 November 2014 20:45:02 Rob Stradling wrote:
>> It would be nice if each browser came with a hardcoded, predetermined
>> date by which the user MUST upgrade to a newer version.  Failure to
>> upgrade by that date would mean that the browser ceases to function
>> (except to permit the user to upgrade).
>>
>> With clear messaging in the UI, would this be an appropriate solution?
> While I agree that deprecating old security sensitive code would be nice,
> I don't think this is something users would welcome in any way.
>
> There would be an outrage.

I agree. But they can't use software with known security holes. That
*MUST* stop. It's comparable to driving without working brakes, and
people are *not aware of it*, and are surprised when they hit the wall.
Car maintenance is mandatory for good reasons, because Granny Anne
otherwise wouldn't do it and endanger herself and others.

The messaging (e.g. on said webpage, and in marketing/update
announcements) should include
1) reasons
2) concrete implications for them and others
3) solutions

People have no concept of the implications of using insecure software,
for themselves and others, and an insecure software doesn't "smell
rotten" - for users, it is indistinguishable from good software. We need
to change that. We need to make it *very* clear and in-the-face which
risk people are taking, in a way that they can't ignore, like rotten
fruit/meat smell.

For example, we could render the Firefox UI background bright red with
exploding mines [1], and add an additional toolbar with warning text,
which links to a webpage explaining things further. It can't be
deactivated. This doesn't stop them from using it, but makes the danger
in-their-face.
[1]
https://addons.mozilla.org/en-US/firefox/addon/simpsons-movie-fire-explosi/

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Yvan Boily-2

> I agree. But they can't use software with known security holes. That
> *MUST* stop. It's comparable to driving without working brakes, and
> people are *not aware of it*, and are surprised when they hit the wall.
> Car maintenance is mandatory for good reasons, because Granny Anne
> otherwise wouldn't do it and endanger herself and others.

While I agree with the sentiment, the bottom line is that the sentiment doesn't reflect reality, and the car analogy, like every other time it gets used, is flawed.

Car maintenance is only mandatory when the deterioration or damage to the vehicle is sufficient to prevent operation of the vehicle.  Car owners may not be able to qualify for insurance, or meet environmental constraints in their region, but that doesn't prevent them driving, it only prevents the transfer of liability that insurance provides.  In every market there are unlicensed drivers, uninsured vehicles, and there are only minimal resources allocated for enforcement of these because it is largely unenforceable without tremendous resources.

The only relation here are the reason that people don't maintain vehicles - cost, capability, consciousness.
* If I don't have the financial resources to repair my car, I won't
* If I don't have the capability (including to hire the capability) to repair my car, I won't
* If I am not conscious of the *need* to repair my car, I won't

> The messaging (e.g. on said webpage, and in marketing/update
> announcements) should include
> 1) reasons
> 2) concrete implications for them and others
> 3) solutions

These address (partly) capability and consciousness.  What if a user doesn't have the capability to install fixes (not just a knowledge thing, disabled users who rely on specialized interfaces that are dependant on specific software versions may be unable to update, etc, etc).  What if the upgraded version has incompatibilities or is unsupported on legacy hardware/OS.  The vast majority of people in the world are not in the financial situation to simply upgrade because there is a technical security risk.  water, shelter, food, and clothing tend to take priority, especially in the developing world, or in poverty stricken parts of the developed world.

> People have no concept of the implications of using insecure software,
> for themselves and others, and an insecure software doesn't "smell
> rotten" - for users, it is indistinguishable from good software. We need
> to change that. We need to make it *very* clear and in-the-face which
> risk people are taking, in a way that they can't ignore, like rotten
> fruit/meat smell.

Using insecure software is a *risk*.  Like anything else, if given a choice between using insecure software and no software, or eating no food, or rotten food, people will take the risk.  
> For example, we could render the Firefox UI background bright red with
> exploding mines [1], and add an additional toolbar with warning text,
> which links to a webpage explaining things further. It can't be
> deactivated. This doesn't stop them from using it, but makes the danger
> in-their-face.

Mozilla's mission is to support user choice, and for some users, that choice will be to use vulnerable tools; letting them know they are out of date is good, stopping them doing things, not so much.  We need to design the services that Mozilla provides to users to be as secure as possible, but not at the cost of taking away user choice, otherwise they will choose a different, less user focused browser vendor.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Chris Hofmann
On 11/18/14 10:38 AM, Yvan Boily wrote:

>> I agree. But they can't use software with known security holes. That
>> *MUST* stop. It's comparable to driving without working brakes, and
>> people are *not aware of it*, and are surprised when they hit the wall.
>> Car maintenance is mandatory for good reasons, because Granny Anne
>> otherwise wouldn't do it and endanger herself and others.
> While I agree with the sentiment, the bottom line is that the sentiment doesn't reflect reality, and the car analogy, like every other time it gets used, is flawed.
>
> Car maintenance is only mandatory when the deterioration or damage to the vehicle is sufficient to prevent operation of the vehicle.  Car owners may not be able to qualify for insurance, or meet environmental constraints in their region, but that doesn't prevent them driving, it only prevents the transfer of liability that insurance provides.  In every market there are unlicensed drivers, uninsured vehicles, and there are only minimal resources allocated for enforcement of these because it is largely unenforceable without tremendous resources.
>
> The only relation here are the reason that people don't maintain vehicles - cost, capability, consciousness.
> * If I don't have the financial resources to repair my car, I won't
> * If I don't have the capability (including to hire the capability) to repair my car, I won't
> * If I am not conscious of the *need* to repair my car, I won't

I'm not sure I I agree with this analogy.

In our case its the car manufacture's showing up with a new car that
they want to drop in your driveway and take your old one a way.

People have been burned by this proposition so many times that they are
reluctant to take the offer now.

Especially when the dealer or repair shops are unresponsive in fixing
the new car after its been dropped off and won't start.

>> The messaging (e.g. on said webpage, and in marketing/update
>> announcements) should include
>> 1) reasons
>> 2) concrete implications for them and others
>> 3) solutions
> These address (partly) capability and consciousness.  What if a user doesn't have the capability to install fixes (not just a knowledge thing, disabled users who rely on specialized interfaces that are dependant on specific software versions may be unable to update, etc, etc).  What if the upgraded version has incompatibilities or is unsupported on legacy hardware/OS.  The vast majority of people in the world are not in the financial situation to simply upgrade because there is a technical security risk.  water, shelter, food, and clothing tend to take priority, especially in the developing world, or in poverty stricken parts of the developed world.
>
>> People have no concept of the implications of using insecure software,

Sure they do.  They've heard the stories of identify theft and loss of
lieftime saving.

They are consciously making the trade off between the that happening to
them, and broken software after upgrade.

The later has a much more real chance of happening to them given the
state of the industry.

Remove regressions and broken software after update, and improve the
confidence around doing updates, and the choice becomes a lot more clear
and the actions much more posititive.


>> for themselves and others, and an insecure software doesn't "smell
>> rotten" - for users, it is indistinguishable from good software.
rotten software is software that breaks after update.  everyone has had
this happen to them.
>>   We need
>> to change that.
yep.  my deifinition of "that" is different than yours.
>> We need to make it *very* clear and in-the-face which
>> risk people are taking, in a way that they can't ignore, like rotten
>> fruit/meat smell.
we need take action not to ship regressions, and build their confidence
the we won't
break them upon update.

-chofmann
> Using insecure software is a *risk*.  Like anything else, if given a choice between using insecure software and no software, or eating no food, or rotten food, people will take the risk.
>> For example, we could render the Firefox UI background bright red with
>> exploding mines [1], and add an additional toolbar with warning text,
>> which links to a webpage explaining things further. It can't be
>> deactivated. This doesn't stop them from using it, but makes the danger
>> in-their-face.
> Mozilla's mission is to support user choice, and for some users, that choice will be to use vulnerable tools; letting them know they are out of date is good, stopping them doing things, not so much.  We need to design the services that Mozilla provides to users to be as secure as possible, but not at the cost of taking away user choice, otherwise they will choose a different, less user focused browser vendor.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Ben Bucksch
In reply to this post by Yvan Boily-2

Chris Hofmann wrote, On 18.11.2014 19:52:
> Remove regressions and broken software after update, and improve the
> confidence

First off, I agree that people have good reasons to hold back from
updating, and the reasons are mostly that Mozilla doesn't do its job
properly. That's granted. (See my private reply to you, where I agreed.)
And I think we should fix this, but I ran against walls within Mozilla.
If you can solve that problem, more power to you (I mean that literally).

Nonetheless, the tradeoff users make is not a good one, and not
sufficiently informed. (See below)

> In our case its the car manufacture's showing up with a new car that
> they want to drop in your driveway and take your old one a way.

I do *not* propose to forcefully take the car away, but to make all the
lights in the dashboard light up. Unlike the dashboard light for
"maintenance cycle" in my car, which comes up after n miles, no matter
whether there's an actual problem or not:
We know that the software has critical security holes, and there's a
very high chance of the user being hacked, and the damage is huge for
them and others. It's actually not just a "risk" in the sense of "Your
house is in an earthquake zone", with a 0.1% chance of happening, but in
the sense of "You're heading straight for the wall there, and you didn't
brake yet", with a 80% chance and literally disastrous results. Users
just can't see that wall coming.

I'm proposing to have warning flashes light up, and clear explanations,
so that people get *acutely* aware of the problem, and can't ignore it /
click it away. They can keep using the software, but they'll have to do
so with the constant awareness that it's insecure. To make security visible.

I think this is better than a forceful removal (timebomb) or forceful
update, because this still leaves room for the exact point in time when
people take care of the matter. Maybe they're in the middle of something
and they can finish that, and take care of it next week. But they can't
ignore and forget it. My suggestion doesn't take choice away. It just
makes it obvious and in-your-face which risk you take.

[Anecdote: I vaguely remember that Mozilla used to have a timebomb, a
long long time ago, active for certain builds only.]

Just like rotten food that smells. Do you think it's a good thing that
rotten food smells? Or would you rather have food full of dangerous
bacteria and worms look and smell good, so that you can eat it happily
and enjoy it? And then get sick after? I think it's great that we can
the state of food is often obvious by its color and smell, it's helpful
and a protection.

People using insecure software *will* have problems. Currently, a
Firefox 17 looks the same as it always did. How would I know that I was
fine 6 months ago and now I am in danger zone, although nothing changed
on my end? That's totally not obvious for average people, it escapes
their logic and experience. I just want to make the state of the
software evident, obvious.

> [Awaremess]
> They've heard the stories of identify theft and loss of lieftime saving.

But they don't understand /how/ it's happening. They perceive hacking as
a force of nature that can happen to anyone using the Internet. It's
obvious from people I speak with, they do not make the connection with
their own behaviour and outdated software.

Ben


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Mook-6
In reply to this post by Ben Bucksch
On 11/17/2014 07:50 AM, Ben Bucksch wrote:
> I'm seeing so many companies using age-old Firefox versions, and I keep
> telling them they can't, and I keep talking to walls.
>
> Even Eclipse SWT is still not supporting FF31 and shows no initiative to
> move. That means a larger number of downstream products use an insecure
> browser. For Eclipse, that's particularly bad: if developers are hacked,
> all their users can be hacked, too. See linux kernel breakins etc.

The problem is that Eclipse SWT (and other embedders) have problems
keeping up with the constantly changing versions of Firefox; their
release schedules don't match.  Taking them as an example, they appear
to have yearly releases at the end of June:
http://projects.eclipse.org/releases/  (Wikipedia says Firefox 31
shipped in July 2014, so that missed the train.)

You keep talking to walls, because what you're telling them is,
effectively, "you can't be using Firefox/Gecko".  That might, in fact,
be true; but they don't exactly have a solution for that, so they're
stuck with limping along with this thing that mostly works but isn't
really supported.

> Mozilla needs to do a much better job in communicating that using old
> browser is not an option. FF24 doesn't *exist* anymore. Nobody gets that
> at the moment.
>
> Some ideas:

Remember that they ship software; they can disable anything you put in
their way that makes their users' experience inferior.  The only
solution that would actually work would be to do what they want, i.e.
have something they can actually ship as an embedder.  My understanding
is that Mozilla (or at least, key smart people in the project who know
this stuff) have decided that working with embedders is not fruitful and
does not plan to support their use cases.  (I'm basing this on the
discussion around rejection of the XUL tree improvements.)

--
Mook
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Hubert Kario
In reply to this post by Chris Hofmann-2
On Tuesday 18 November 2014 08:28:29 Chris Hofmann wrote:

> On 11/18/14 8:13 AM, Hubert Kario wrote:
> > On Monday 17 November 2014 20:45:02 Rob Stradling wrote:
> >> It would be nice if each browser came with a hardcoded, predetermined
> >> date by which the user MUST upgrade to a newer version.  Failure to
> >> upgrade by that date would mean that the browser ceases to function
> >> (except to permit the user to upgrade).
> >>
> >> With clear messaging in the UI, would this be an appropriate solution?
> >
> > While I agree that deprecating old security sensitive code would be nice,
> > I don't think this is something users would welcome in any way.
> >
> > There would be an outrage.
> >
> > We never should do anything that will (or can) impact users directly.
>
> The way to breakdown the fear that users have about upgrades is
> to to produce higher quality software, for Firefox, but also across
> the industry.   The fear comes from running into serious regressions
> that make the software unusable after the upgrade.  The fear is well
> grounded.  Think about it.  Has it ever happened to you?
>
> The difference between you and the users we are talking about
> is you usually have the skills and understanding to dig yourself
> out, or find other options if the upgrade is truly broken.
>
> The fear is compounded for those that don't have these skills.
>
> Make better software, and do a lot more testing before unleashing
> upgrades on the world and this problem can be reduced or might
> even go away, but it would take much more time and effort
> to repair the damage and loss of confidence that has been done.
>
> -chofmann

Problem is that some changes by definition will cause regressions.

What if the website used weak keys in certificates or weak signature
algorithms and we have disabled support for them in new version?

What if the website supports just SSLv3 and we disable it?

--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Kurt Roeckx
In reply to this post by Chris Hofmann-2
On 2014-11-19 12:34, Hubert Kario wrote:
> Problem is that some changes by definition will cause regressions.
>
> What if the website used weak keys in certificates or weak signature
> algorithms and we have disabled support for them in new version?
>
> What if the website supports just SSLv3 and we disable it?

I think there are 3 things we should consider:
- New features that enhance the security
- Security bugs (that can be exploited)
- Changes in the parsing that result in websites looking different or no
longer working.

New features that enhance the security:
There have been various issues when introducing TLS 1.1 and 1.2, and as
a result some websites stop to work.  And it's not because of bugs in
firefox/nss, but either on the other side or something in between.

There are other features that enhance the security that resulted in some
websites breaking or not rendering correctly.  And you could also argue
that those websites have always been broken.  We just become more strict
in what we allow.

And I believe all those new features are important, specially if you use
it to browse on the internet.  But the question is at which point are
those things so important that everybody should be using it.

I don't know what the embedded things do exactly, but they might not
care about this.


Security bugs:
We want everybody to use a browser that doesn't have bugs that can be
exploited.  This is what is currently fixed in the ESR releases and I
don't think we add the new features from the previous point in them.

I'm not sure those who embed would use an ESR release and then actually
update things when a new ESR is released.  But depending on how it's
used it might also not be important.


Changes in the parsing:
This is about being backward (or bug) compatible with previous version.
  For instance something used to be in the Mozilla namespace but we no
longer support that.  Or we used to interpret something wrong and it was
fixed resulting in it looking differently.

I believe that in certain environments this is very important.  They
have some internal web server that works with a certain version and is
hard to get fixed and are generally afraid to update things because it
might break things.

I also think those would love to have an ESR version that is longer
supported than the current 1 year.


Kurt

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Hubert Kario
----- Original Message -----

> From: "Kurt Roeckx" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, 19 November, 2014 2:27:13 PM
> Subject: Re: Communicating that unsupported browsers cannot be used
>
> On 2014-11-19 12:34, Hubert Kario wrote:
> > Problem is that some changes by definition will cause regressions.
> >
> > What if the website used weak keys in certificates or weak signature
> > algorithms and we have disabled support for them in new version?
> >
> > What if the website supports just SSLv3 and we disable it?
>
> I think there are 3 things we should consider:
> - New features that enhance the security
> - Security bugs (that can be exploited)
> - Changes in the parsing that result in websites looking different or no
> longer working.

Regressions introduced by fixes for each of those classes of changes
are different for us, not for a user that has problem updating in general.

For them a regression is a regression, no matter the cause.

Yes, we should work to make sure we implement features as they are defined
and that they keep on working like this, but it's not like we can preserve
every little detail about how the software works.

See also: http://xkcd.com/1172/

--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

ianG-2
In reply to this post by Hubert Kario
On 19/11/2014 11:34 am, Hubert Kario wrote:

> On Tuesday 18 November 2014 08:28:29 Chris Hofmann wrote:
>> On 11/18/14 8:13 AM, Hubert Kario wrote:
>>> On Monday 17 November 2014 20:45:02 Rob Stradling wrote:
>>>> It would be nice if each browser came with a hardcoded, predetermined
>>>> date by which the user MUST upgrade to a newer version.  Failure to
>>>> upgrade by that date would mean that the browser ceases to function
>>>> (except to permit the user to upgrade).
>>>>
>>>> With clear messaging in the UI, would this be an appropriate solution?
>>>
>>> While I agree that deprecating old security sensitive code would be nice,
>>> I don't think this is something users would welcome in any way.
>>>
>>> There would be an outrage.
>>>
>>> We never should do anything that will (or can) impact users directly.
>>
>> The way to breakdown the fear that users have about upgrades is
>> to to produce higher quality software, for Firefox, but also across
>> the industry.   The fear comes from running into serious regressions
>> that make the software unusable after the upgrade.  The fear is well
>> grounded.  Think about it.  Has it ever happened to you?
>>
>> The difference between you and the users we are talking about
>> is you usually have the skills and understanding to dig yourself
>> out, or find other options if the upgrade is truly broken.
>>
>> The fear is compounded for those that don't have these skills.
>>
>> Make better software, and do a lot more testing before unleashing
>> upgrades on the world and this problem can be reduced or might
>> even go away, but it would take much more time and effort
>> to repair the damage and loss of confidence that has been done.
>>
>> -chofmann
>
> Problem is that some changes by definition will cause regressions.
>
> What if the website used weak keys in certificates or weak signature
> algorithms and we have disabled support for them in new version?
>
> What if the website supports just SSLv3 and we disable it?


Yes, it goes down.

But what's the alternative?  Leave them up forever?

The industry-wide flaw here is that it pushes out this stuff, says it's
secure, takes the money ... but when it stops being secure, the industry
isn't to be found.  The users get no help.

This is the same fraud found across the CA industry, the browser sector,
the IETF, everywhere.  It's secure today, but there's no answer for
tomorrow.

So, now as the insecurity legacy builds up and starts to bite, what to do?

There is required a short term answer -- break sites -- and a long term
answer -- fix the process so that we can deal with it in the future.



iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Kevin Chadwick-2
In reply to this post by Ben Bucksch
On Tue, 18 Nov 2014 17:42:45 +0100
Ben Bucksch wrote:

> I agree. But they can't use software with known security holes. That
> *MUST* stop.

Unless they only use that browser to access a local server or use
it only through a VPN. In which case you would simply be annoying them
and making them check the gpg sig of a new package more often.

WRT to VMs then like MAC's they actually account for additional
complexity and exploits so unless you have exhausted priv sep and DACs
then that would be the less secure option.

qmail, dovecot spring to mind and check out OpenBSD's tcpdump or sshd
or relayd or the new httpd or opensmtpd for priv sep done well, and even
some windows application software has it's own users. Maybe firefox
could use that method rather than chromes more limited? version.

Finally the only firefox that could be given the title of secure would
be a much simpler silverfox with security as it's primary goal over
speed and features and I'm sure firefox would benefit greatly from that
too with better and leaner implementations of some features. Ironically,
security seems to be a poor relation in the browser world.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Ben Bucksch
In reply to this post by Ben Bucksch
Kevin Chadwick wrote, On 25.11.2014 00:10:
> Unless they only use that browser to access a local server or use
> it only through a VPN. In which case you would simply be annoying them
> and making them check the gpg sig of a new package more often.

If the browser is truly disconnected from the Internet, it won't be able
to do the update, either.

Most local servers embed at least *some* remote content, e.g. load
remove images, iframes, or open external links within the same browser.
That's already enough to be at risk.

Most people *think* they are fine, but they just don't realize the depth
and extend of the danger. From my experience, 99.9% of people who think
they are fine are actually not.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

RE: Communicating that unsupported browsers cannot be used

UMK Dikshit
In reply to this post by Kevin Chadwick-2
But there are other things to be considered like Connectivity "How many people are connected to the Internet 24x365?".And also the people who are on metered connections they don't update there system software because the MB will be wasted.If we implement the anything like cease to function until you upgrade they move on to other browsers and this will impact the "Firefox UserBase" and also Mozilla.
And some people don't know that they have to update the software and some don't know "How to Update?".If we want a secured browser then we have to educate the people about the importance of "Security" and "How to implement or use it?".And to stay secure in the World Of Internet.
Regarding the Update or Upgrade regularly we have to explain them the need and How? Why? it should be done.And also see that we use High Standards of Security in the Browser.    
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Communicating that unsupported browsers cannot be used

Kevin Chadwick-2
In reply to this post by Ben Bucksch
On Tue, 25 Nov 2014 18:27:38 +0100
Ben Bucksch wrote:

> If the browser is truly disconnected from the Internet, it won't be able
> to do the update, either.
>

? I thought the point was a date after which it stopped functioning or
do you mean won't allow itself to run untill updated, in which case I
would like to agree but know that in some circumstances (no js enabled
etc.) then you may know the update and that the risk does not apply for
a quick banking payment that must be done right now before you leave
the building etc..

Software should never choose for the user but make things easy and
being insistent is fine.

> Most local servers embed at least *some* remote content, e.g. load
> remove images, iframes, or open external links within the same browser.
> That's already enough to be at risk.

But not all clients have internet access or local servers, remote
content.


This from another list may be of interest to this list but I've raised
and repeated a part I'd like to highlight as it seems that some don't
believe that security is highly regarded by mozilla as stated recently
in this very thread.

"A note however: it would be very nice if Firefox would fork, chroot,
and drop privileges on the renderer. Perhaps I shouldn't say this
without having Mozilla's opinion on such a scheme, but Mozilla seems
more interested in shiny redesigns. As Theo said to your inquiry about a
secure image viewer, such behavior is rare outside OpenBSD."
_________________________________________________________________________

> Summary
> -------
> As described in another thread
> (<http://marc.info/?l=openbsd-misc&m=141677224322425&w=1>),
> I'm trying to run firefox as a non-privileged user _firefox, talking
> to my X server (no Xephyr yet) via an ssh tunnel.  But I've discovered
> a serious flaw in this scheme: cut-n-paste is completely broken.  In
> fact, it looks like cut-n-paste from any X client with a diferent
> uid/gid than the X server is broken. :(
>
> My basic question is, is there any way to fix this?  

This is the point, of course, that the client cannot communicate with
the host X server. It's not just from a different uid. I think the
easiest solution would be to write a script which you can run in a host
xterm "ffpaste ..." which makes ... the clipboard in the Xephyr window.
Of course you could probably also write a script to sync the clipboard
automatically (and in fact this is the top result for a Google search
"Xephyr copy paste"), but perhaps this would default the purpose of
running Firefox in a different X server.

Oh I'm sorry, I read that wrong. If you use Xephyr the clients cannot
communicate clipboards (of course they can communicate otherwise if they
are running as the same user). The above is right for a client in
Xephyr.

I can, however, paste into an X client running on another machine in the
same X server. I don't have a local SSH server and didn't try that, but
I fail to see why that shouldn't work since it goes over the network
irregardless of what user the process runs as. But that X client can
talk to all the other X clients on this server and that defeats the
whole point of all this.

A note however: it would be very nice if Firefox would fork, chroot, and
drop privileges on the renderer. Perhaps I shouldn't say this without
having Mozilla's opinion on such a scheme, but Mozilla seems more
interested in shiny redesigns. As Theo said to your inquiry about a
secure image viewer, such behavior is rare outside OpenBSD.

>
>
>
> Details:
> -------
>
> Lenovo Thinkpad T60, 3GB RAM + 6GB swap.  Fresh install of OpenBSD 5.6
> from the CD, updated to -stable as of 2014-11-19.  My usual login is
> in login class staff, for which I've edited /etc/login.conf to set the
> memoryuse, datasize, and stacksize limits (all both -cur and -max) to
> 'infinity', so there should be enough memory for firefox to run ok.
>
> I use twm(1) as my window manager.  firefox is the 5.6 package, but
> I've renamed the binary:
>
> # cd /usr/local/bin; mv firefox firefox.bin
>
> I used adduser(8) to create a new unpriviliged user _firefox,
> group _firefox, no other group memberships, login class staff.
> I've set up ssh authentication so I can ssh to _firefox.
>
> Now, in an xterm, call it xterm #1:
> % ssh -X -i $HOME/.ssh/firefox_id_rsa _firefox@localhost
>
> This gives me a shell (in that same xterm #1) running as uid/gid
> _firefox, with ssh proxying and tunneling X back to my X server.
> (I'm not using Xephyr(1) at this point.)
>
> Now, in the _firefox shell,
>
> $ firefox.bin &
>
> I get a a couple of warning messages that the ssh proxy/tunnel is
> lacking some X protocol extensions
>
> Xlib:  extension "RANDR" missing on display "localhost:10.0".
> Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
>
> but then firefox starts and runs fine.
>
> Now suppose I try to cut-n-paste some text from the firefox window to
> (say) a vi (in insert mode) which is running in some other xterm window
> (call this one xterm #2).  [For twm, 'cut-n-paste' means double- or
> triple-left-click to select, then middle-click to paste.]  This goes
> badly awry:
> * the cut appears to work normally (text is highlighted)
> * the paste appears to be a no-op, ... but
> * a few seconds later, the target xterm window (#2) disappears (and
>   the vi and xterm processes are gone)
>
>
>
> To see if this is a firefox issue, or a more generic problem with
> cut-n-paste between X clients running with different uid/gid, I tried
> starting an xterm instead of a firefox process.  That is, from the
> _firefox shell, I typed
>
> $ xterm &
>
> and in the newly-started xterm (call it xterm #3) typed a few commands
> to put some text on the screen
>
> $ echo hello world
> hello world
> $ banner hello
>
>  #    #  ######  #       #        ####
>  #    #  #       #       #       #    #
>  ######  #####   #       #       #    #
>  #    #  #       #       #       #    #
>  #    #  #       #       #       #    #
>  #    #  ######  ######  ######   ####
>
> $
>
> then I tried to cut-n-paste the banner 'hello' text from xterm #3
> into somewhere else.
>
> The result was that the cut operation killed the xterm #3 window, with
> the following X error message displayed back in the _firefox shell
> running in xterm #1:
>
> $ xterm &
> [1] 25801
> $ xterm: warning, error event received:
> X Error of failed request:  BadAccess (attempt to access private resource denied)
>   Major opcode of failed request:  18 (X_ChangeProperty)
>   Serial number of failed request:  599
>   Current serial number in output stream:  600
>
> [1] + Done (83)            xterm
> $
>
> (Interestingly, I had no problem cut-n-pasting that error text from
> xterm #1 into a vi (in insert mode) over in still another xterm window.
>
>
>
> What I conclude from all of this is that (apparently) my window manager
> and/or X server have noticed that {firefox, xterm #3} are running as
> uid/gid _firefox/_firefox, while my {window manager, X server} have my
> usual (different) uid/gid, so the cut-n-paste attempt (indeed, the cut
> itself, judging by the xterm error message) is blocked.
>
> So... questions:
> * is this indeed what's going on?
> * it's been a long time since I tried cut-n-paste from a 'remote'
>   window; is this what usually happens [I'll try some tests...]?
> * what piece of software is enforcing this security policy?
>   (once I find that out, then I can investigate if/how the policy
>   might be configured to be more suitable to my needs)
> * given my underlying goal of trying to exploit-mitigate firefox
>   (<http://marc.info/?l=openbsd-misc&m=141616701418506&w=1>),
>   what other options are there for handling cut-n-paste?
>   (Maybe xcutsel(1) and/or xclipboard(1) would be useful here?)
>
> ciao,
>
> --
> -- "Jonathan Thornburg [remove -animal to reply]" <[hidden email]>
>    Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
>    "There was of course no way of knowing whether you were being watched
>     at any given moment.  How often, or on what system, the Thought Police
>     plugged in on any individual wire was guesswork.  It was even conceivable
>     that they watched everybody all the time."  -- George Orwell, "1984"  

-- Martin Brandenburg
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security