CVE-2017-14482 - Red Hat Customer Portal

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

CVE-2017-14482 - Red Hat Customer Portal

ken-93
Security vulnerability in emacs v.25.2 & earlier:


https://access.redhat.com/security/cve/CVE-2017-14482

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Kaushal Modi
This has already been fixed in the recently released Emacs 25.3 (emergency
release to fix just that).

It would be recommended to update to Emacs 25.3. If that is not possible,
then apply the workaround mentioned in that link.

On Thu, Sep 21, 2017, 5:52 PM ken <[hidden email]> wrote:

> Security vulnerability in emacs v.25.2 & earlier:
>
>
> https://access.redhat.com/security/cve/CVE-2017-14482
>
> --

Kaushal Modi
Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

ken-93
On 09/21/2017 06:03 PM, Kaushal Modi wrote:

>
> This has already been fixed in the recently released Emacs 25.3
> (emergency release to fix just that).
>
> It would be recommended to update to Emacs 25.3. If that is not
> possible, then apply the workaround mentioned in that link.
>
>
> On Thu, Sep 21, 2017, 5:52 PM ken <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Security vulnerability in emacs v.25.2 & earlier:
>
>
>     https://access.redhat.com/security/cve/CVE-2017-14482
>
> --
>
> Kaushal Modi
>
Many people, including myself, have systems with package managers...
which have dependencies... all of which make upgrading outside of
package management unfeasible.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Alberto Luaces
ken writes:

> Many people, including myself, have systems with package
> managers... which have dependencies... all of which make upgrading
> outside of package management unfeasible.

The workaround doesn't require installing nor upgrading nothing.

--
Alberto


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Emanuel Berg-4
Alberto Luaces wrote:

>> Many people, including myself, have systems
>> with package managers... which have
>> dependencies... all of which make upgrading
>> outside of package management unfeasible.
>
> The workaround doesn't require installing nor
> upgrading nothing.

Yes it does - it requires installing the
workaround :)

Obviously the corrected version in the
repositories is ideal.

It would be interesting to see the original
code that created this vulnerability. I mean,
so you know what *not* to write... ehem.

Also, it would be interesting to learn how it
was discovered. Wait, don't tell me! It was an
antivirus program, right? That program would
sure be interesting to see as well ;)

--
underground experts united
http://user.it.uu.se/~embe8573


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

ken-93
In reply to this post by Alberto Luaces
On 09/22/2017 03:37 AM, Alberto Luaces wrote:
> ken writes:
>
>> Many people, including myself, have systems with package
>> managers... which have dependencies... all of which make upgrading
>> outside of package management unfeasible.
> The workaround doesn't require installing nor upgrading nothing.
>
Which is why I included the link... which you can find in my original post.



Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Emanuel Berg-4
ken wrote:

>>> Many people, including myself, have systems
>>> with package managers... which have
>>> dependencies... all of which make upgrading
>>> outside of package management unfeasible.
>>>
>> The workaround doesn't require installing
>> nor upgrading nothing.
>>
> Which is why I included the link... which you
> can find in my original post.

I don't understand all the antagonism, if
that's what it is. Ken did good. The only one
who did comparably good is Ryu.

--
underground experts united
http://user.it.uu.se/~embe8573


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Mario Castelán Castro-2
In reply to this post by Emanuel Berg-4
On 22/09/17 02:48, Emanuel Berg wrote:
> It would be interesting to see the original
> code that created this vulnerability. I mean,
> so you know what *not* to write... ehem.

That is the problem with nearly all contemporary programs: Instead of
verifying that they are correct; it is verified that they are not
incorrect according to a small set of ways in which a program may be
incorrect. This idea doomed to fail is the foundation of conventional
testing, SMT testing (as in Klee), lint-like tools and manual source
code auditing.

Paraphrasing Dijkstra, all these methods can prove that a program is
incorrect, but almost never (only trivial toy programs) can prove that
it is correct.

Only verifying that programs are correct using formal logic and an
appropriate specification can eliminate software bugs (hardware can
always malfunction, because of ionizing radiation, “metastability” of
flip-flops, because somebody disconnects the power cord, and many other
things).

At present there is limited infrastructure for verified programming, but
it can be done. See e.g.: https://cakeml.org/.

--
Do not eat animals; respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan


signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Emanuel Berg-4
Mario Castelán Castro wrote:

> That is the problem with nearly all
> contemporary programs: Instead of verifying
> that they are correct; it is verified that
> they are not incorrect according to a small
> set of ways in which a program may be
> incorrect. [...]

Also, formal verification that is applied on
a model will only prove that *the model* is
correct, not the real thing.

There is one automated way of testing that
I know of that actually works, and that is for
shell tools that have the super-simple text
interface where the tool accepts a limited set
of arguments. Say that it accepts one integer
as the first argument and then one string as
its second. Then it is trivial to setup a test
program that will just invoke repeatedly with
randomized integers and strings. Because its
random, it might find borderline cases which
makes absolutely no sense (but still shouldn't
break the program), but which supposedly
rational human beings would never think of
to input, and thus without the test program,
would never get tested.

But for a huge software system like Emacs,
formal verification being obviously out of the
question, even simple-minded brute-force
testing is difficult to set up, at least for
anything bigger than the smallest module.el.
So the byte-compiler and style checks
(`checkdoc-current-buffer') is what you got.

Instead, I think the best way to test is just
to have lots of people using it. At least major
flaws will surface really soon this way.

There are also languages like Dafny where you
can state formally what a function should do,
and the verification tool will match that to
your code. Problem is, it isn't refined to any
degree where it actually will matter for
every-day programming. Often, the code will be
correct, and the formal description is correct
as well, only the verifier will still say it
doesn't compute. And programming should
obviously not be about tinkering with code and
expressions that already makes sense, just so
that the computer will agree it does.
So straight down the line, this will amount to
toy/demo programs as well.

Here is an example:

    method Main () {
      var n := f(4, 5);
      print "The result is ";
      print n;
    }

    method f(a:int, b:int) returns (r:int)
      requires a >= 0;
      requires b >= 0;
      ensures  r == 4*a + b;
    {
      r := 0;
      var i := 0;
      var j := 0;
      while (i < a || j < b)
        decreases a + b - (i + j);
        invariant 0 <= i <= a;
        invariant 0 <= j <= b;
        invariant r == 4*i + j;
      {
        if (j < b) {
          r := r + 1;
          j := j + 1;
        }
        else {
          r := r + 4;
          i := i + 1;
        }
      }
    }

There is a Dafny mode for Emacs, and with Mono
(because it is an .NET thing to begin with),
perhaps one could hook that up into a neat IDE.
Still, it will only amount to poor Dafny.

--
underground experts united
http://user.it.uu.se/~embe8573


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Charles A. Roelli
In reply to this post by Mario Castelán Castro-2
The code that caused CVE-2017-14482 (aka Bug#28350) was 100% correct.
It was also far too powerful, so its behavior had to be properly
limited.  There is no way to find such a "bug" without reading the
code and trying to understand its use.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Óscar Fuentes
[hidden email] (Charles A. Roelli) writes:

> The code that caused CVE-2017-14482 (aka Bug#28350) was 100% correct.
> It was also far too powerful, so its behavior had to be properly
> limited.

The two sentences above are contradictory.

> There is no way to find such a "bug" without reading the
> code and trying to understand its use.

Maybe, in the Elisp case, this is true, but not in the general case.


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Eli Zaretskii
> From: Óscar Fuentes <[hidden email]>
> Date: Sat, 23 Sep 2017 14:53:36 +0200
>
> [hidden email] (Charles A. Roelli) writes:
>
> > The code that caused CVE-2017-14482 (aka Bug#28350) was 100% correct.
> > It was also far too powerful, so its behavior had to be properly
> > limited.
>
> The two sentences above are contradictory.

Not really.  But they don't tell the whole story: the vulnerability
was actually caused by Gnus, MH-E, and perhaps other MUAs who decided
to automatically support enriched text, without checking the code
first.  Otherwise, enriched.el per se has/had no problem whatsoever.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Glenn Morris-3
Eli Zaretskii wrote:

> But they don't tell the whole story: the vulnerability was actually
> caused by Gnus, MH-E, and perhaps other MUAs who decided to
> automatically support enriched text, without checking the code first.
> Otherwise, enriched.el per se has/had no problem whatsoever.

I disagree. Simply opening a file in an unpatched Emacs can run
arbitrary code with zero prompting. This is a massive security risk that
is entirely internal to enriched.el (possibly with the 'display property
more generally). It does get worse that Gnus would trust enriched.el to
decode mail messages too. But anyone using Emacs from 21.1 to 25.2
should be aware of this issue, whether or not they use Emacs for mail.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Eli Zaretskii
> From: Glenn Morris <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 23 Sep 2017 13:18:59 -0400
>
> Eli Zaretskii wrote:
>
> > But they don't tell the whole story: the vulnerability was actually
> > caused by Gnus, MH-E, and perhaps other MUAs who decided to
> > automatically support enriched text, without checking the code first.
> > Otherwise, enriched.el per se has/had no problem whatsoever.
>
> I disagree. Simply opening a file in an unpatched Emacs can run
> arbitrary code with zero prompting.

How did that file end up in a directory you can access?  Why are you
visiting a file about which you know nothing at all?

And how is that different from a Lisp package that creates display
properties out of thin air?

> This is a massive security risk that is entirely internal to
> enriched.el (possibly with the 'display property more generally).

More generally, Emacs itself.  Even more generally, any software you
use.

> It does get worse that Gnus would trust enriched.el to decode mail
> messages too. But anyone using Emacs from 21.1 to 25.2 should be
> aware of this issue, whether or not they use Emacs for mail.

If you use software you didn't write, you are at risk.  If you don't
want the risk of ending up in a car crash, the only way is not to
leave home.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Bob Proulx
In reply to this post by ken-93
ken wrote:
> Many people, including myself, have systems with package managers... which
> have dependencies... all of which make upgrading outside of package
> management unfeasible.

That's great!  Using distributions with security teams much simplifies
things for the end user.  Otherwise every user would need to closely
follow each and every one of the zillion software projects installed
on their system.  Software packaging makes this simpler.

In which case the best answer for people using pre-packaged emacs is
to install the security upgrade from their distribution which includes
the fix.

Spot checking things now (some days later) and it looks like the major
distributions I looked at have already released fixed versions
available for people using those distros to install.  Just upgrade to
them.  Life is good!

Bob


Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Yuri Khan-2
In reply to this post by Eli Zaretskii
On Sun, Sep 24, 2017 at 12:34 AM, Eli Zaretskii <[hidden email]> wrote:

> Why are you visiting a file about which you know nothing at all?

Why not? Opening a file in a text editor is not normally considered a
hazardous activity.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Mario Castelán Castro-2
In reply to this post by Emanuel Berg-4
On 22/09/17 17:14, Emanuel Berg wrote:
> Also, formal verification that is applied on
> a model will only prove that *the model* is
> correct, not the real thing.

You seem to be confused, verifying that a program is correct *requires*
a model. Verifying the model is a different and separate task.

> […] Then it is trivial to setup a test
> program that will just invoke repeatedly with
> randomized integers and strings. […]

Random testing is very inefficient because most inputs are garbage and
are treated uniformly by the program under test. For example, feeding
random input to a compiler will result almost surely in only ill-formed
programs and thus will not exercise anything but the parser. Good
testing must exercise code paths that only run in rare corner cases and
the probability that random testing achieves this is very small.

But like I said, testing is fundamentally flawed. Testing can tell you
that a program is defective, but not that a program is free from defects!

> There are also languages like Dafny where you
> can state formally what a function should do,
> and the verification tool will match that to
> your code. […]

Taking a glance at Danfy, it seems like it trusts the answers of a SMT
solver (Microsoft's Z3) and does not generate proofs of correctness (but
I can easily be wrong; I did not check in deep because I dislike .NET).
This is not what I am referring about when I say “proving programs
correct”. I mean software like CakeML <https://cakeml.org/>. It is
linked to a proof assistant (HOL4). You can develop there the
specification of the program and prove it correct according to the
specification.

There is still much work to be done to make formal verification tools
like this more usable, but it must be noted that in the case of CakeML
it *already* works. CakeML is itself formally verified using HOL4.

Unfortunately there is little documentation material to learn to use
CakeML. Using HOL4 or other proof assistant requires at least a solid
intuition for formal logic and some knowledge in mathematics. Anybody
wanting to call himself a programmer must become comfortable with using
a proof assistant because this is a prerequisite to writing correct
software. *ANY* other approach leads to defective software, *especially*
ordinary testing[1].

Notes:

[1]: There is also software that is not itself proved correct, but
generates a solution for a problem along with a proof that the solution
is correct. For example, many SAT solvers meet this description.
Provided one can verify the proof, one can the ascertain that the
solution is correct, but the program may still generate incorrect
“solutions” in other cases.

--
Do not eat animals; respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan


signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Eli Zaretskii
In reply to this post by Yuri Khan-2
> From: Yuri Khan <[hidden email]>
> Date: Sun, 24 Sep 2017 03:50:51 +0700
> Cc: "[hidden email]" <[hidden email]>
>
> On Sun, Sep 24, 2017 at 12:34 AM, Eli Zaretskii <[hidden email]> wrote:
>
> > Why are you visiting a file about which you know nothing at all?
>
> Why not? Opening a file in a text editor is not normally considered a
> hazardous activity.

A file whose source you don't trust or are unfamiliar with should
initially be examined with find-file-literally, if your security is
indeed important for you.  That emulates what most other text editors
do when you open a file.

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Emanuel Berg-4
In reply to this post by Mario Castelán Castro-2
Charles A. Roelli wrote:

> The code that caused CVE-2017-14482 (aka
> Bug#28350) was 100% correct. It was also far
> too powerful, so its behavior had to be
> properly limited. There is no way to find such
> a "bug" without reading the code and trying to
> understand its use.

Agree 100%

--
underground experts united
http://user.it.uu.se/~embe8573
Reply | Threaded
Open this post in threaded view
|

Re: CVE-2017-14482 - Red Hat Customer Portal

Emanuel Berg-4
In reply to this post by ken-93
Bob Proulx wrote:

> That's great! Using distributions with
> security teams much simplifies things for the
> end user. Otherwise every user would need to
> closely follow each and every one of the
> zillion software projects installed on their
> system. Software packaging makes
> this simpler.

Yes, except for some cases, because it requires
that enough people use it so that the stuff is
kept up to date.

For example, there should be many lispers
reading this. SBCL, ECL, CCL, what have you.
Take a look at the software in your repos.
Compare it to the versions you'd find on the
web. People aren't cool enough in general for
the really cool people to find what they want.

Why it has to be like this I have no idea.
Why can't you get the latest stuff the
same way?

And it is not about getting the bleeding edge
just for the sake of it. Some stuff is really,
really outdated and there is no way around it
except bypassing the package
manager altogether.

--
underground experts united
http://user.it.uu.se/~embe8573
1234