Task terminated with unhandled exception: Invalid path entry #1630

Open
marcioapm opened this Issue Nov 23, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@marcioapm
Contributor

marcioapm commented Nov 23, 2016

Task terminated with unhandled exception: Invalid path entry: H:\Own files\Eigene Dokumente\Travel\160704_Ihla.docx

We get these sometimes. It seems like some browser or someone malicious is passing some oddly formatted string as the file name, which vibe fails to parse. This is an assert in the PathEntry ctor.
It happens while parsing the request, before any of my code runs.

Unfortunately, I have no idea what the full path passed is nor do I have a callstack, but I assume it's being called from splitPath()

I think sanitation should happen before hand, and errors should be gracefully dealt with in this case. I could then handle bad paths on my application code, but as it is, I have no chance of doing so.

@marcioapm

This comment has been minimized.

Show comment
Hide comment
@marcioapm

marcioapm Mar 7, 2017

Contributor

More info: core.exception.AssertError@../../../../root/.dub/packages/vibe-d-0.7.30/vibe-d/source/vibe/inet/path.d(426): Invalid path entry: U:\PERSO\25-3-17_Ch_Blr.docx

@s-ludwig any chance of a quick fix? anything will work, but killing the event loop with an assert makes this an easy DoS channel

Contributor

marcioapm commented Mar 7, 2017

More info: core.exception.AssertError@../../../../root/.dub/packages/vibe-d-0.7.30/vibe-d/source/vibe/inet/path.d(426): Invalid path entry: U:\PERSO\25-3-17_Ch_Blr.docx

@s-ludwig any chance of a quick fix? anything will work, but killing the event loop with an assert makes this an easy DoS channel

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Mar 23, 2017

Member

I'll have a look at this. It's probably okay (necessary anyway) to relax the rules a bit. The new Path implementation in vibe-core still has this issue, but it can be fixed there, because the path has a kind associated with it (windows, posix or inet).

However, in this case the right thing to do would be to parse this as a Windows path, whereas it will currently be parsed as a system native path. So to maybe find a higher level solution, do you know where the path originates from? A form upload? vibe-core defines and uses a new PathEntry.validateFilename function that I could backport to 0.7.31.

In addition to converting the assertion to an exception, the form upload code could then also attempt to sanitize the file name, of course.

Member

s-ludwig commented Mar 23, 2017

I'll have a look at this. It's probably okay (necessary anyway) to relax the rules a bit. The new Path implementation in vibe-core still has this issue, but it can be fixed there, because the path has a kind associated with it (windows, posix or inet).

However, in this case the right thing to do would be to parse this as a Windows path, whereas it will currently be parsed as a system native path. So to maybe find a higher level solution, do you know where the path originates from? A form upload? vibe-core defines and uses a new PathEntry.validateFilename function that I could backport to 0.7.31.

In addition to converting the assertion to an exception, the form upload code could then also attempt to sanitize the file name, of course.

s-ludwig added a commit that referenced this issue Mar 23, 2017

@glathoud

This comment has been minimized.

Show comment
Hide comment
@glathoud

glathoud Dec 13, 2017

Hello, hopefully this helps: I just observed this on one of my vibe.d-based servers:

Task terminated with unhandled exception: Invalid path entry: %{(#test='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#req=@org.apache.struts2.ServletActionContext@getRequest()).(#res=@org.apache.struts2.ServletActionContext@getResponse()).(#res.setContentType('text/html;charset=UTF-8')).(#res.getWriter().print('security_')).(#res.getWriter().print('check')).(#res.getWriter().flush()).(#res.getWriter().close())}

This seems to be related to an Apache Struts2 exploit: rapid7/metasploit-framework#8064

Hello, hopefully this helps: I just observed this on one of my vibe.d-based servers:

Task terminated with unhandled exception: Invalid path entry: %{(#test='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#req=@org.apache.struts2.ServletActionContext@getRequest()).(#res=@org.apache.struts2.ServletActionContext@getResponse()).(#res.setContentType('text/html;charset=UTF-8')).(#res.getWriter().print('security_')).(#res.getWriter().print('check')).(#res.getWriter().flush()).(#res.getWriter().close())}

This seems to be related to an Apache Struts2 exploit: rapid7/metasploit-framework#8064

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