Possible exploit potential in dosemu.
The dosemu binary has a rwx stack segment, so this means that instructions can be placed on the stack and executed. This makes it a lot easier to exploit than in the stack was rw-
This is detected with the following tool:
/src/dosemu-1.3.3 $ scanelf -Req *
RWX --- --- 1.3.3.0/bin/dosemu.bin !WX --- --- src/env/video/remap_asm.o !WX --- --- src/env/video/vesabios_pm.o
What this means is that the dosemu.bin file is RWX stack. The source objects src/env/video/remap_asm.o and src/env/video/vesabios_pm.o cause this.
Please refer to the following URL for an explanation.
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
I think option (3) is the cause, and can be fixed by adding the following to the end of the two source files:
#ifdef __ELF__
.section .note.GNU-stack,"",%progbits
#endif
This will indicate to the gnu assembler that an executable stack is not required.
I hope this helps
Kind Regards
James
Quoted 6 lines · James Courtier-Dutton
The dosemu binary has a rwx stack segment, so this means that instructions can be placed on the stack and executed. This makes it a lot easier to exploit than in the stack was rw-
The source objects
src/env/video/remap_asm.oandsrc/env/video/vesabios_pm.ocause this.
There were actually a few other files too, namely the 16bit bios.o and vesabios.o files; those were not found by the tool you referred too. Not surprisingly because they were linked in a strange way.
It's been corrected in SVN changes 1622 and 1623.
Thanks,
Bart
Quoted 8 lines · Bart Oldeman
Quoted 6 lines · James Courtier-Dutton
The dosemu binary has a rwx stack segment, so this means that instructions can be placed on the stack and executed. This makes it a lot easier to exploit than in the stack was rw-
The source objects
src/env/video/remap_asm.oandsrc/env/video/vesabios_pm.ocause this.
Quoted 8 lines
There were actually a few other files too, namely the 16bit bios.o and vesabios.o files; those were not found by the tool you referred too. Not surprisingly because they were linked in a strange way.
It's been corrected in SVN changes 1622 and 1623.
Thanks,
Bart
Thank you. It is an easy thing to fix, and makes it considerably more difficult for a cracker to develop and exploit.