ASLR revisited

ASLR revisited

[John Selbie]

For my open source project, I publish source code for Unix written in C++.
And as a convenience, I publish Win32 binaries compiled with Cygwin's g++
build. I bundled the compiled EXE along with the dependent Cygwin DLLs
(cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll).

Someone rang me up today and said, "We're about to go live with your
pre-compiled binaries for Windows, but our compliance testing detected your
code isn't using ASLR (Address Space Layout Randomization).  Can you fix?"

A quick internet search reveals that Cygwin has a compatibility issue with
ASRL. Process Explorer from sysinternals.com reveals that the process runs
without ASLR.

I tried using the Windows 10 Exploit Protection Panel - and specifying an
exception for this executable to have mandatory ASLR. That results in the
code no longer running.  Although the alternate option of "Botton-up ASLR"
did allow the code to run, but Process Explorer still doesn't show it
running with ASLR.

Is there a workaround for allowing Cygwin code to have ASLR?  I don't need
the fork() function.

Thanks,
jrs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ASLR revisited

[John Selbie]

And I just discovered that recompiling with this added to the g++ command
line:

 -Xlinker --dynamicbase

Seems to work. Or at the least, triggers the process to show up in Process
Explorer as ASLR?

Good idea to continue with this?



On Mon, Mar 2, 2020 at 8:26 PM John Selbie <jselbie@gmail.com> wrote:

> For my open source project, I publish source code for Unix written in C++.
> And as a convenience, I publish Win32 binaries compiled with Cygwin's g++
> build. I bundled the compiled EXE along with the dependent Cygwin DLLs
> (cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll).
>
> Someone rang me up today and said, "We're about to go live with your
> pre-compiled binaries for Windows, but our compliance testing detected your
> code isn't using ASLR (Address Space Layout Randomization).  Can you fix?"
>
> A quick internet search reveals that Cygwin has a compatibility issue with
> ASRL. Process Explorer from sysinternals.com reveals that the process
> runs without ASLR.
>
> I tried using the Windows 10 Exploit Protection Panel - and specifying an
> exception for this executable to have mandatory ASLR. That results in the
> code no longer running.  Although the alternate option of "Botton-up ASLR"
> did allow the code to run, but Process Explorer still doesn't show it
> running with ASLR.
>
> Is there a workaround for allowing Cygwin code to have ASLR?  I don't need
> the fork() function.
>
> Thanks,
> jrs
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ASLR revisited

[Lee]

On 3/2/20, John Selbie  wrote:
> And I just discovered that recompiling with this added to the g++ command
> line:
>
>  -Xlinker --dynamicbase
>
> Seems to work. Or at the least, triggers the process to show up in Process
> Explorer as ASLR?
>
> Good idea to continue with this?

I haven't looked at this in ages, but for gcc I use

LDFLAGS="${LDFLAGS} -Wl,--nxcompat"
# https://en.wikipedia.org/wiki/Data_Execution_Prevention
#   Enable DEP with -Wl,--nxcompat

LDFLAGS="${LDFLAGS} -Wl,--dynamicbase,--export-all-symbols"
# https://en.wikipedia.org/wiki/Address_space_layout_randomization
# https://stackoverflow.com/questions/24283918/how-can-i-enable-aslr-dep-and-safeseh-on-an-exe-in-codeblocks-using-mingw
#   ASLR with gcc has a problem: -Wl,--dynamicbase doesn't emit the
necessary relocation table.
#   As a workaround, you can pass -Wl,--dynamicbase,--export-all-symbols

Regards,
Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: ASLR revisited

[Andrey Repin]

Greetings, John Selbie!

> For my open source project, I publish source code for Unix written in C++.
> And as a convenience, I publish Win32 binaries compiled with Cygwin's g++
> build. I bundled the compiled EXE along with the dependent Cygwin DLLs
> (cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll).

> Someone rang me up today and said, "We're about to go live with your
> pre-compiled binaries for Windows, but our compliance testing detected your
> code isn't using ASLR (Address Space Layout Randomization).  Can you fix?"

> A quick internet search reveals that Cygwin has a compatibility issue with
> ASRL. Process Explorer from sysinternals.com reveals that the process runs
> without ASLR.

As far as I recall, POSIX forking semantics are incompatible with ASLR.
So, if my memory serves me well, the answer is "don't do that, your
application will break badly."

> Is there a workaround for allowing Cygwin code to have ASLR?  I don't need
> the fork() function.

Build your application for native API. That's the only right answer.


-- 
With best regards,
Andrey Repin
Wednesday, March 4, 2020 22:09:21

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple