Out of Memory (crash) on infinite loop #2781
Comments
|
The endless loop here is If you add Ruby Sass and Dart Sass do the same thing here. Intended behaviour, I guess. @nex3, Should |
|
This is expected; the |
|
Crashing on an infinite seems like a reasonable thing to do.
…On Tue., 4 Dec. 2018, 10:54 am Natalie Weizenbaum ***@***.*** wrote:
This is expected; the + operation by default converts its arguments to
strings and concatenates them. Whether it *should* be so permissive is an
open question, but even if not I don't think it's worth breaking
backwards-compatibility to fix.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2781 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWH8R5RcXHkTysjS8mRgeOK7jNpGNks5u1bmggaJpZM4Y-ByH>
.
|
|
The original file has no problem and only a simple extra symbol like '/' or '&' crashes the sassc program. I guess that sometime such extra symbol may introduced in by typos. I am not sure whether there could be some governors in libsass (like an upper bound on loop)? When we are writing code (C/C++/Java), we know the compilers will not crash on our typos or small errors. I am not sure whether sass file is some kind of "code", and sassc could show equivalent robustness. |
|
@zyingp Sass functions more like a programming language interpreter than a compiler, in the sense that it directly runs users' programs rather than compiling them to an intermediate format before running them. A more direct comparison would be to what a C, C++, or Java program would do if you ran a loop that continually allocated more and more memory. For C and C++, it would certainly crash in the same way LibSass is doing here. Java is more sophisticated about its memory management and would probably throw a more graceful error once its memory ceiling was reached, but it would still produce an error of some kind. |
|
I agree with what @nex3 said, sass functions are closer to real programming logic, so it is indeed possible that any input file creates endless loops, thus consuming memory ad infinite. Unfortunately in c++ this means it will segfault at some point due to exhausting the stack (depending on the underlying stack memory limitations). IMO we can't catch this type of errors in a portable way (heap out of memory should already be catched though). Adding a counter and enforcing an upper limit may work for most scenarios, but it does only hide the underlying issue, while crippling the maximum on most envs and also has a performance impact. IMO this should be closed as "will not fix" due to "as designed, user input issue". On a side note: these kind of issues seem more important for eg. sassmeister or libsass srcmap inspector, since it allows some kind of DOS for remotely available system. But we always had this issue, and I personally use GRSEC/SELINUX to circumvent it. |
I know some services have a hard time out on compilations to mitigate DOS attacks from this vector. |
|
I agree the comments aboves. This is essentially by design. |
|
@xzyfer Could you please tell, How this issue has fixed here? |
|
@rjoshi18 This issue is closed as "won't fix" / "works as intended" ("by design"). |
glebm
changed the title
|
Assigned CVE-2018-19826 |
|
Why assign a CVE to something that wasn't accepted as a bug/issue |
|
I am not assigning these. I am just adding the references so that they are easier to find. |
Some malformed input could cause the libsass/sassc program out of memory and crashes. These malformed files are not big and are simply adding an extra '/' or '&' in original files (created by fuzzing). The problem can be reproduced both in version 3.5.5 and the master branch (accessed on 2018/12/2) code.
Sample malformed input files include https://github.com/zyingp/temp/blob/master/sass_mem_37, and https://github.com/zyingp/temp/blob/master/sass_mem_38 .
Run
./sassc sass_mem_37sass_mem_37
For example, sass_mem_37 looks like below, where the '&' symbol before 1 is extra:
(Similar, the sass_mem_38 file, the '/' is added later https://github.com/zyingp/temp/blob/master/sass_mem_38)
Call stack
Since the problem will crash so when I randomly stop the problem, the call stacks looks like below:
Where in Sass::Inspect::operator()(Sass::String_Quoted*) at inspect.cpp:728, the
append_token(s->value(), s);line thesbecomes a very long string (1.foo 1.foo 1.foo 1.foo 1.foo...) and is keeping increasing. Seems the problem enters some endless loop. The memory footprint of the program grows quickly (to 1GB and above) and later the problem is killed by the system.The text was updated successfully, but these errors were encountered: