bugGNU nano - Bugs: bug #53269, direct leak of 104 byte(s) of...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #53269: direct leak of 104 byte(s) of memory

Submitted by:  Ashish Kunwar <dorkerdevil>
Submitted on:  Fri 02 Mar 2018 05:06:22 PM UTC  
Votes:  100  
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Closed

( Jump to the original submission)

Fri 30 Mar 2018 09:22:14 AM UTC, comment #17: 

Fix was released in 2.9.5.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 11 Mar 2018 07:24:06 PM UTC, comment #16: 

The leak has been fixed in git, commit e8505b2d.

Thanks again for reporting.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 06 Mar 2018 05:25:44 AM UTC, comment #15: 

Ashish, can you attach that crash file with a simpler name? For example: "crashesnano".

Hey Benno,
i have renamed the crash file to "crashesnano" and works same as the original one.and attached it

I have created a video poc on vimeo and hadded as password protected.

url: https://vimeo.com/258738568
pass: pass is the above filename

(file #43472)

Ashish Kunwar <dorkerdevil>
Mon 05 Mar 2018 07:36:24 PM UTC, comment #14: 

Ashish, I don't see any new attachment to this bug.  But... the real question is: can you make nano crash with that file?  Or is it just another false positive, like the 178 that afl has found here by now?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 05 Mar 2018 11:46:21 AM UTC, comment #13: 

Yes the reproduction file I attached can be tried for ease and it does the same work as the original one.

#Brian is involved so.. You can contact him too.

Ashish Kunwar <dorkerdevil>
Mon 05 Mar 2018 10:23:11 AM UTC, comment #12: 

Well, I have installed afl, and after running for an hour, it thinks to have found 129 unique crashes.  But... I can open each of those 129 "crash files" without a problem.  So... afl's thoughts about what constitutes a crash seem to be a bit off?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 05 Mar 2018 08:32:56 AM UTC, comment #11: 

Thanks, Brian, for the explanation.  Much appreciated.

Strangely, I cannot download the file that is supposed to crash nano: Savannah gives an Error, saying that the filename in the URL does not match the one recorded in the database.  :|  Apparently Savannah has bugs too.

Ashish, can you attach that crash file with a simpler name?  For example: "crashesnano".

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 03 Mar 2018 04:44:41 PM UTC, comment #10: 

I think he was confused on how to reproduce a crash triggered by AFL. His fuzzing command line was ‘afl-fuzz -m none -i input_dir -o output_dir — ./nano -v -‘ where nano is just viewing a file from STDIN. To reproduce the crash he should have just ran ‘./nano -v file_name’ but instead he told nano to read from STDIN and then read the crash reproducer which produced the memory leak. Nice unintended bug find though. Not sure if he has actually reproduced a crash but that is what id:000000,sig:06,src:000005,op:flip1,pos:A8 is, the reproducer file for whatever AFL though caused a crash.

Brian Carpenter <geeknik>
Sat 03 Mar 2018 04:42:17 PM UTC, comment #9: 

that is not just a strange long filename
references here
http://lcamtuf.coredump.cx/afl/README.txt

Ashish Kunwar <dorkerdevil>
Sat 03 Mar 2018 04:35:30 PM UTC, comment #8: 

Oh, and when you close nano with ^X, I don't think it reopens -- it just looks that way because you're running it in some kind of debugger and things go slow?  The first ^X just closes the first buffer (the stuff read from standard input, "-"), and the second ^X closed the second buffer, the one with the strange long file name that you used: "id:000000,sig:06,src:000005,op:flip1,pos:A8".

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 03 Mar 2018 04:31:14 PM UTC, comment #7: 

I don't understand what "id:000000,sig:06,src:000005,op:flip1,pos:A8" is doing on one of your command lines.  Nano sees it as a file name.  If instead you use README, or some other simple file name, you will get the same result: 104 bytes lost.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 03 Mar 2018 01:33:23 PM UTC, comment #6: 

yeah i totally understand what you means , so now let me explain what i did and how i triggered it.

so i compiled the nano with afl-gcc and g++ with AFL_HARDEN=1
and after i fuzzed the nano with a 1.txt file which contains simple text

"Hello world!"

and with appropriate commands like
./nano -v -
#stdin

and i got the crash file generated by afl-fuzz
#that is the crash file i attached

so now i used that crash file (i attached ) to test
with this command

./nano -v -  id:000000,sig:06,src:000005,op:flip1,pos:A8

and i got

==4603=ERROR: LeakSanitizer: detected memory leaks
Direct leak of 104 byte(s) in 1 object (s) allocated from:
#0 0x7f148a4ddf602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602
#1 0x4ecac5 in nmalloc /root/nano-2.9.3/src/utils/utils.c:354

Summary: Direct leak of 104 byte(s) in 1 object (s)....

#some points to note
after giving the above commands to triage the crash or reproduce the crash
nano opened and then i pressed x to close but it then reopen with the crash fileand then again i closed it gave me the above mesaage.

Ashish Kunwar <dorkerdevil>
Sat 03 Mar 2018 01:28:22 PM UTC, comment #5: 

(The "Gone undo line" bug has been reported as bug #53272.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 03 Mar 2018 01:21:05 PM UTC, comment #4: 

I have no idea what a POC is.  And I don't know what to do with a crash file -- and even if I knew, you will understand that I won't touch any binary files.

The problem can hardly be in utils.c, because nmalloc() does not have the ability to lose track of a pointer.  The mistake must be somewhere higher in the chain: nmalloc() is called by add_undo() from text.c, which is called from read_file() in files.c, which is...  I don't see how any of these can lose track of an undo record when reading from standard input, especially since I can undo the things that were read in.

However, when more than a single line was read from standard input, and you undo them, and then you try to redo them, it says "[ Gone undo line -- please report a bug ]".  So somewhere something is wrong.  But maybe this is a different bug, I'll report it separately.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 03 Mar 2018 03:06:05 AM UTC, comment #3: 

sorry for wrong keyword its Fuzzer,
Problem is in utils.c file
As its leaking 104 byte(s) from utils

Ashish Kunwar <dorkerdevil>
Sat 03 Mar 2018 03:02:11 AM UTC, comment #2: 

The file I attached is a crash file generated by the fizzer as a poc

Ashish Kunwar <dorkerdevil>
Fri 02 Mar 2018 07:09:39 PM UTC, comment #1: 

Hello Ashish,

Thanks for the report.  I can reproduce with the following, simpler recipe:

    nano  -  second

When I run that in valgrind, and type some characters, followed by ^D ^D ^X N ^X, it says:

==13703== 104 bytes in 1 blocks are definitely lost in loss record 392 of 481
==13703==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13703==    by 0x12B772: nmalloc (utils.c:354)
==13703==    by 0x126AE8: add_undo (text.c:1224)
==13703==    by 0x111DAF: read_file (files.c:759)
==13703==    by 0x11E3DB: scoop_stdin (nano.c:1164)
==13703==    by 0x11FDFB: main (nano.c:2590)

Somehow an undo record gets lost, but only when after standard input (-) another file is mentioned on the command line.  Weird.  Will look into it.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 02 Mar 2018 05:06:22 PM UTC, original submission:  

Hello, my name is Ashish Kunwar a security researcher from India.
so i was testing nano v2.9.3
with following commands
~/ nano -v - id:000000,sig:06,src:000005,op:flip1,pos:A8

so i got crash

==4603=ERROR: LeakSanitizer: detected memory leaks

Direct leak of 104 byte(s) in 1 onject (s) allocated from:
#0 0x7f148a4ddf602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602
#1 0x4ecac5 in nmalloc /root/nano-2.9.3/src/utils/utils.c:354

#i have attached the poc file used in

Ashish Kunwar <dorkerdevil>

 

Attached Files
file #43472:  crashesnano added by dorkerdevil (389B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by geeknik (Posted a comment)
  • -email is unavailable- added by dorkerdevil
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by dorkerdevil (Voted in favor of this item)
  • -email is unavailable- added by dorkerdevil (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 100 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-30 bens Open/ClosedOpen => Closed
    2018-03-11 bens Severity3 - Normal => 2 - Minor
        StatusNone => Fixed
    2018-03-06 dorkerdevil Attached File- => Added crashesnano, #43472
    2018-03-03 dorkerdevil Carbon-Copy- => Added geeknik@protonmail.ch
    2018-03-02 bens Assigned toNone => bens
        SummaryDirect leak of 104 byte(s) memory => direct leak of 104 byte(s) of memory
    2018-03-02 dorkerdevil Carbon-Copy- => Added dorkerdevil
    2018-03-02 dorkerdevil Attached File- => Added id%3A000000,sig%3A06,src%3A000005,op%3Aflip1,pos%3A8, #43438

    Back to the top


    Powered by Savane 3.5