grsecurity forums

Hello,

I have a CGI module compiled by Kylix. When I try to execute it on my provider
it doesn't work and the provider reports about the following error:

==============================================================================
Here is the server error text:
PAX: From 213.145.98.9: terminating task:
/home/profotos/www/www/cgi-bin/keygen(keygen):19184, uid/euid: 937/937, PC:
08173f1f, SP: 5ffffa38
PAX: bytes at PC: 83 44 24 04 dc e9 93 a6 ed ff 83 44 24 04 dc e9 9d a6 ed ff

It seems that your program is trying to execute the memory stack, which is
not allowed for security reasons.
==============================================================================

It seems that my provider uses grsecurity patch and it generates that error.
Actually these bytes are data bytes (not a code) so it's just a false alarm.
Is it possible to fix this error in the next versions of grsecurity?
I can send my CGI module for a test, if you give me e-mail address.

Thanks!

Alex.

alexsolo wrote:Here is the server error text:
PAX: From 213.145.98.9: terminating task:
/home/profotos/www/www/cgi-bin/keygen(keygen):19184, uid/euid: 937/937, PC:
08173f1f, SP: 5ffffa38
PAX: bytes at PC: 83 44 24 04 dc e9 93 a6 ed ff 83 44 24 04 dc e9 9d a6 ed ff

It seems that your program is trying to execute the memory stack, which is not allowed for security reasons.

they're half right, PaX caught an execution attempt from a non-executable page, but it's not on the stack but most likely on the heap (the brk() managed one) or in the .data/.bss/something-not-executable sections of the main executable.

Actually these bytes are data bytes (not a code) so it's just a false alarm. Is it possible to fix this error in the next versions of grsecurity?

the reported bytes represent valid intel machine code so it's most likely a problem with Kylix itself (i take a wild guess and say that this code has something to do with exception handling). the problem cannot be fixed in PaX, at least not without giving up some security (namely, this code sequence could be emulated much like the gcc trampolines) but i won't do it. instead you should tell Borland about the problem, they can easily fix it. if you need a solution in the meantime, you can chpax -sp it (before uploading) and it should work (unless your provider uses a modified patch which doesn't allow disabling PaX). note that this is a bad workaround as your module will run without the non-executable page protection.

I can send my CGI module for a test, if you give me e-mail address.

for now it'd be enough to post the readelf -e output to see where this code comes from.

PaX Team wrote:for now it'd be enough to post the readelf -e output to see where this code comes from.

I'm sorry, I haven't Linux on my PC so I can just post a link to my CGI:

http://aspr.vdll.com/keygen.cgi

It's not a CGI directory so you can download it easily.

Thanks!

alexsolo wrote:http://aspr.vdll.com/keygen.cgi

khm, given what the filename suggests, it's probably not a good idea to expose it widely on the internet . anyway, about the problem: if this is the same binary that was run on your provider's host when the PaX log message was generated, then there are several issues. first, the fault address is within the .rodata section (which is not executable), second, the contents at the fault address are different from the log, suggesting that .rodata has been modified at runtime (.rodata is read-only). third, due to the section ordering in the executable, .rodata is not actually read-only as it comes after .data and hence was put into a writable ELF segment (i.e., the linker script that was used to produce the executable is wrong). all three issues are likely the result of the tool chain that built your executable, i.e., something you cannot correct yourself, only Borland could. feel free to contact them and give them the url to this thread, their programmers will have enough technical details here so that finding/correcting the problems will be easy (assuming Kylix doesn't want to generate code at runtime, if it does, then your only remedy is chpax).

Alexsolo,

I have had the same problem. After my provider installed these patches all the compiled cgi on my sites went down. I have search Borland’s site high and low and can’t find any mention or help on this at all.

Does anyone know the latest?

fcarrie wrote:Does anyone know the latest?

i've had no more feedback on this, so i guess Borland didn't fix anything. did you try the chpax -sp trick?

PaX Team wrote:

fcarrie wrote:Does anyone know the latest?

i've had no more feedback on this, so i guess Borland didn't fix anything. did you try the chpax -sp trick?

Yes, my provider did this and it worked fine. However they say it is only a temporary solution. I guess next time they do a server reboot (there are 4 servers with my stuff on them) I will be back to square one and they will have to the chpax –sp thing over again. It’s a bit of a pain. It is next to impossible to find out anything more about this, certainly from Borland anyway. I cannot believe that myself and alexsolo are the only ones to have this problem, especially as Borland products are so widely used.

fcarrie wrote:Yes, my provider did this and it worked fine. However they say it is only a temporary solution. I guess next time they do a server reboot (there are 4 servers with my stuff on them) I will be back to square one and they will have to the chpax –sp thing over again. It’s a bit of a pain.

no, the chpax settings will survive a reboot fine as they are a mark in the given executable. what they won't survive is a recompile since that creates a new file, but you can always run chpax on your executables before uploading them yourself.

Pax team – thank you very much for this information, I had not realised this. You have been a great help. One question, where do I get the chpax program?

fcarrie wrote:Pax team – thank you very much for this information, I had not realised this. You have been a great help. One question, where do I get the chpax program?

http://pax.grsecurity.net/ then choose the proper chpax version (i take it your provider uses recent kernels so you'll need the .tar.gz not the old version of chpax). there are also chpax packages in certain distributions, may be easier to grab those if you're their user.

Sorry to be a pain,

is the chpax program stand alone? I downloaded it (chpax-06.tar.gz) and have compiled it using the makefile provided, it does not report any errors but it will not run. I take it the syntax is

chpax –sp <my progam name> ?

fcarrie wrote:is the chpax program stand alone? I downloaded it (chpax-06.tar.gz) and have compiled it using the makefile provided, it does not report any errors but it will not run. I take it the syntax is

chpax –sp <my progam name> ?

yes it's standalone, yes it runs quietly unless -v specified, and yes that'd be the correct syntax for your case. when you said it wouldn't run, what exactly happened?

PaX Team wrote:yes it's standalone, yes it runs quietly unless -v specified, and yes that'd be the correct syntax for your case. when you said it wouldn't run, what exactly happened?

Pax Team -
The executable is in the directory and the persimmons are set to 757 , but lynix does not seem to recognise it as such when I attempt to run it. “command not found” Perhaps I have not compiled it properly. What is the recommended “make” syntax?

Sorry about this BTW Pax Team, it is likely to be my fault as I have just undergone eye surgery and am having great difficulty seeing very well right now!

Thanks

Fred

fcarrie wrote:The executable is in the directory and the persimmons are set to 757 , but lynix does not seem to recognise it as such when I attempt to run it. “command not found” Perhaps I have not compiled it properly. What is the recommended “make” syntax?

i take it that the current directory is not on your PATH, you can either run it as ./chpax or just do a make install and that will put it into /sbin by default.

PaX Team wrote:

fcarrie wrote:The executable is in the directory and the persimmons are set to 757 , but lynix does not seem to recognise it as such when I attempt to run it. “command not found” Perhaps I have not compiled it properly. What is the recommended “make” syntax?

i take it that the current directory is not on your PATH, you can either run it as ./chpax or just do a make install and that will put it into /sbin by default.

Oops … ……… Told you I wasn’t seeing properly. All working just fine now.

Many thanks to the Pax Team, far more helpful than my service provider