[Security] Don't use this library

[TheBlusky]

This library has many security flaws.

Author has been contacted to see how to handle it.

I'll give details about the issue when it will be corrected.

In the mean time, I advise you not to use it / disable it if used in production.

[valassis-nick]

Considering how this project seems to be abandoned, and there have been no pushes to the repository in almost 2 years, you're better serving the community by either:

Documenting the flaws openly in this issue so that potential users can make their own determinations about whether or not to use the library.

OR

Forking and making the corrections yourself and linking them to this issue.

I don't think being dramatic and secretive helps anyone.

[TheBlusky]

I am neitheir dramatic nor secretive. You're right, this project is old and seems unmaintened, however, it is still used (you can check it directly on github or npm), and I don't want to cause them any problem.

[DanielRuf]

Do you mean the issues shown by npm audit? Or a real vuln in the project itself?

[tex0l]

@DanielRuf he means a real vulnerability that can be exploited with a crafted pptx.

[DanielRuf]

Not sure. If this is the case please report it to npm inc or Snyk, they will handle the next steps (contact owner/maintainer).

I'm not aware of such vuln.

[tex0l]

The author of this issue @TheBlusky has done so (I work with him), but got no answer.

I was merely confirming the existence of the vulnerability (I came across the project again today and saw your question), and how it can be exploited so that anyone thinking of using this project won't.

[DanielRuf]

Then do a (responsible) disclosure, it makes not much sense to wait forever.

[DanielRuf]

If you mean this, it's not that critical and as you have already disclosed it I would say this issue is resolved.

https://dan.lousqui.fr/xss-vulnerability-report-for-pptx2html-en.html

[tex0l]

Yes I mean this, thank you for posting the link for everyone. Injecting an arbitrary script via a crafted pptx is basically the worst case scenario of a vuln such a project could have..

I think it's better to leave this issue open until the owner closes it so that people who come across the project know this vuln exists.

[DanielRuf]

A sandbox escape, memory access using buffer overflow or similar would be worse.

[TheBlusky]

My first comment was created when I contacted the author (see the timeline in my article).

The issue is not fixed (yet ?) therefore it should not be marked as resolved.

This is a Javascript library for browsers. If the issue was an escape from the browser then it would be a browser issue.

When using this kind of library, it's 99% meant to be implemented in an HTML application.

XSS on an HTML application is the worst that could happen client side, it means complete control over the application (client side) of a victim for an attacker. If someone uses this library for hosted content, it might be stored XSS, that means that victims might be scaled and not targeted.

More than that, if the application is used by Electron (or other "software in html" library), XSS might be used for remote command execution on the operating system...

So basically, even though it could be worse, if you use it on a complex application hosting pptx or a desktop / mobile app using JS bridges, it's still critical.

If someone still wants to use it in his own project, he should be sure to check twice (or more) his risk evaluation.

[DanielRuf]

Please contact npm inc again to get the advisory published.

The rest is clear.