Hi,
In my chase to get Windows certified DLL's that fulfill the above mentioned security requirements I was successful with the people from SQLite. The following DLL passes the Certification 3.4 test.
http://stakepoint.com/other/sqlite3.zip
As the discussion was interesting I copied the whole threat.
Maarten MOSTERT
28 Av Alphonse Denis
83400 Hyères, France
+33 676411296
http://stakepoint.com/
> -----Original Message-----
> From: [hidden email] [mailto:sqlite-users-
> [hidden email]] On Behalf Of Keith Medcalf
> Sent: vrijdag 3 april 2015 01:51
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
> NXCheck - DBCheck
>
>
> BTW, I have verified that these options all work as described and the
options
> are recognized and processed properly by Windows, and that BinScope is
> happy:
>
> Failed checks
> d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL )
>
> Passed checks
> d:\source\sqlite\sqlite3.dll - NXCheck ( PASS )
This makes all the allocated memory and stack not-executable
> d:\source\sqlite\sqlite3.dll - DBCheck ( PASS )
> (Note, position independent code (PIC) is by definition loadable at any
base.
> Microsoft is just several decades behind in generating position
independent
> code.)
And this makes it possible to load the DLL above 2 GB, which by default
isn't enabled because too much existing legacy code still casts pointers to
integers and back.. Another opt-in flag in the header, to allow existing
programs to still work on bigger machines.
SafeSEH is a similar flag for Structured Exception Handling. Without this
flag the stack is unwound on exceptions by using debugger tricks and
information stored on the stack itself. When this flag is set the compiler
promises to provide all this information in a parsable format somewhere in
the binary. This improves performance and reliability on these exceptions.
But as far as I know Sqlite doesn't use structured exception handling at
all. Perhaps MingW supports a flag of just telling that, if it doesn't
support creating these tables.
(In Windows x86_64 these tables are always required, so this flag doesn't
apply there)
Windows 8.1 and Windows 10 will add another feature like this where all
callback function pointers are stored in a central table for verification if
a passed callback function is really to the intended code. (As far as I know
this is currently only supported by internal and pre-release versions of the
MSVC compiler)
Bert
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
I hate correcting myself. You do not need the --export-all-symbols
Using it will cause all non-static symbols to be exported (even without a specific dllexport) just like using -shared on unices.
---
Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why.
>-----Original Message-----
>From: [hidden email] [mailto:sqlite-users-
>[hidden email]] On Behalf Of Keith Medcalf
>Sent: Thursday, 2 April, 2015 17:51
>To: General Discussion of SQLite Database
>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
>NXCheck - DBCheck
>
>
>BTW, I have verified that these options all work as described and the
>options are recognized and processed properly by Windows, and that
>BinScope is happy:
>
>Failed checks
>d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL )
>
>Passed checks
>d:\source\sqlite\sqlite3.dll - NXCheck ( PASS )
>d:\source\sqlite\sqlite3.dll - DBCheck ( PASS )
>
>(Note, position independent code (PIC) is by definition loadable at any
>base. Microsoft is just several decades behind in generating position
>independent code.)
>
>---
>Theory is when you know everything but nothing works. Practice is when
>everything works but no one knows why. Sometimes theory and practice are
>combined: nothing works and no one knows why.
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:sqlite-users-
>>[hidden email]] On Behalf Of Keith Medcalf
>>Sent: Thursday, 2 April, 2015 17:43
>>To: General Discussion of SQLite Database
>>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
>>NXCheck - DBCheck
>>
>>
>>add the following linker options with MinGW:
>>
>>-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-
>symbols
>>
>>You may or may not need -static-libgcc or the linker -Bstatic options
>>unless you are also enabling things that require MingW DLL runtime
>>support (such as using the -mthreads option to make the DLL thread
>>exception safe).
>>
>>-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware
>>
>>Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the
>>linker (so you can add them to the shell tool and other pre-built
>>executables as well). Files also need to export the symbol table (hence
>>the --export-all-symbols). --large-address-aware sets the (you guessed
>>it) large address aware flag which basically means that you are using
>>unsigned pointers and not signed pointers (that is, you understand that
>>neither disk space nor memory comes in negative sizes) and don't diddle
>>with your pointers (eg, assigning magical meaning to bits in the
>>pointer). This allows use of more than 2GB of virtual address space per
>>process on systems that support it (ie, 32-bit userland on a 64-bit
>>Windows -- on 64-bit Windows windows does not co-habitate with 32-bit
>>processes, instead a wee trampoline is installed in the top 100MB or so
>>of the virtual space to thunk back and forth to the OS -- making it
>>impossible to insert code into the OS from a 32-bit process, while 64-
>bit
>>processes on 64
>> -bit windows have full and complete access to the OS as it resides in
>>each processes address space) or if the /3GB boot option is set on 32-
>bit
>>OSes (so the OS is forced to shoehorn into the top 1GB of each process).
>>
>>The only thing this does not fix is the Exception Handlers. But that
>>particular protection is not implemented by gcc (not needed because of
>>non-ill-conceived design?). However, you might still want to add -
>>mthreads and the static linking options to the build so that the GCC
>>threadsafe exception handlers are used.
>>
>>---
>>Theory is when you know everything but nothing works. Practice is when
>>everything works but no one knows why. Sometimes theory and practice
>are
>>combined: nothing works and no one knows why.
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:sqlite-
>users-
>>>[hidden email]] On Behalf Of Richard Hipp
>>>Sent: Thursday, 2 April, 2015 14:25
>>>To: General Discussion of SQLite Database
>>>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck
>-
>>>NXCheck - DBCheck
>>>
>>>On 4/2/15, Random Coder <[hidden email]> wrote:
>>>>
>>>> I'd recommend the SQLite team turn them on for the version of the DLL
>>>> they distribute, but I'm honestly not sure if there are negative side
>>>> effects to doing so.
>>>
>>>That's not possible, unfortunately, We compile the published DLL
>>>(the 32-bit DLL at least) with MinGW so that they will work on older
>>>versions of Windows. If we used a recent MSVC then the resulting DLL
>>>will not work on WinXP, I am told.
>>>
>>>If the published DLL is not to your liking, it is simple to make your
>>>own. I suggest you do so. You can start with the amalgamated source
>>>code file "sqlite3.c". All you need is to compile that one file into
>>>a DLL that the security checker approves of. How hard can that be?
>>>
>>>--
>>>D. Richard Hipp
>>>[hidden email]
>>>_______________________________________________
>>>sqlite-users mailing list
>>>[hidden email]
>>>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>>
>>
>>_______________________________________________
>>sqlite-users mailing list
>>[hidden email]
>>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
BTW, I have verified that these options all work as described and the options are recognized and processed properly by Windows, and that BinScope is happy:
Failed checks
d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL )
Passed checks
d:\source\sqlite\sqlite3.dll - NXCheck ( PASS )
d:\source\sqlite\sqlite3.dll - DBCheck ( PASS )
(Note, position independent code (PIC) is by definition loadable at any base. Microsoft is just several decades behind in generating position independent code.)
---
Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why.
>-----Original Message-----
>From: [hidden email] [mailto:sqlite-users-
>[hidden email]] On Behalf Of Keith Medcalf
>Sent: Thursday, 2 April, 2015 17:43
>To: General Discussion of SQLite Database
>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
>NXCheck - DBCheck
>
>
>add the following linker options with MinGW:
>
>-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols
>
>You may or may not need -static-libgcc or the linker -Bstatic options
>unless you are also enabling things that require MingW DLL runtime
>support (such as using the -mthreads option to make the DLL thread
>exception safe).
>
>-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware
>
>Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the
>linker (so you can add them to the shell tool and other pre-built
>executables as well). Files also need to export the symbol table (hence
>the --export-all-symbols). --large-address-aware sets the (you guessed
>it) large address aware flag which basically means that you are using
>unsigned pointers and not signed pointers (that is, you understand that
>neither disk space nor memory comes in negative sizes) and don't diddle
>with your pointers (eg, assigning magical meaning to bits in the
>pointer). This allows use of more than 2GB of virtual address space per
>process on systems that support it (ie, 32-bit userland on a 64-bit
>Windows -- on 64-bit Windows windows does not co-habitate with 32-bit
>processes, instead a wee trampoline is installed in the top 100MB or so
>of the virtual space to thunk back and forth to the OS -- making it
>impossible to insert code into the OS from a 32-bit process, while 64-bit
>processes on 64
> -bit windows have full and complete access to the OS as it resides in
>each processes address space) or if the /3GB boot option is set on 32-bit
>OSes (so the OS is forced to shoehorn into the top 1GB of each process).
>
>The only thing this does not fix is the Exception Handlers. But that
>particular protection is not implemented by gcc (not needed because of
>non-ill-conceived design?). However, you might still want to add -
>mthreads and the static linking options to the build so that the GCC
>threadsafe exception handlers are used.
>
>---
>Theory is when you know everything but nothing works. Practice is when
>everything works but no one knows why. Sometimes theory and practice are
>combined: nothing works and no one knows why.
>
>>-----Original Message-----
>>From: [hidden email] [mailto:sqlite-users-
>>[hidden email]] On Behalf Of Richard Hipp
>>Sent: Thursday, 2 April, 2015 14:25
>>To: General Discussion of SQLite Database
>>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
>>NXCheck - DBCheck
>>
>>On 4/2/15, Random Coder <[hidden email]> wrote:
>>>
>>> I'd recommend the SQLite team turn them on for the version of the DLL
>>> they distribute, but I'm honestly not sure if there are negative side
>>> effects to doing so.
>>
>>That's not possible, unfortunately, We compile the published DLL
>>(the 32-bit DLL at least) with MinGW so that they will work on older
>>versions of Windows. If we used a recent MSVC then the resulting DLL
>>will not work on WinXP, I am told.
>>
>>If the published DLL is not to your liking, it is simple to make your
>>own. I suggest you do so. You can start with the amalgamated source
>>code file "sqlite3.c". All you need is to compile that one file into
>>a DLL that the security checker approves of. How hard can that be?
>>
>>--
>>D. Richard Hipp
>>[hidden email]
>>_______________________________________________
>>sqlite-users mailing list
>>[hidden email]
>>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
add the following linker options with MinGW:
-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols
You may or may not need -static-libgcc or the linker -Bstatic options unless you are also enabling things that require MingW DLL runtime support (such as using the -mthreads option to make the DLL thread exception safe).
-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware
Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the linker (so you can add them to the shell tool and other pre-built executables as well). Files also need to export the symbol table (hence the --export-all-symbols). --large-address-aware sets the (you guessed it) large address aware flag which basically means that you are using unsigned pointers and not signed pointers (that is, you understand that neither disk space nor memory comes in negative sizes) and don't diddle with your pointers (eg, assigning magical meaning to bits in the pointer). This allows use of more than 2GB of virtual address space per process on systems that support it (ie, 32-bit userland on a 64-bit Windows -- on 64-bit Windows windows does not co-habitate with 32-bit processes, instead a wee trampoline is installed in the top 100MB or so of the virtual space to thunk back and forth to the OS -- making it impossible to insert code into the OS from a 32-bit process, while 64-bit processes on 64
-bit windows have full and complete access to the OS as it resides in each processes address space) or if the /3GB boot option is set on 32-bit OSes (so the OS is forced to shoehorn into the top 1GB of each process).
The only thing this does not fix is the Exception Handlers. But that particular protection is not implemented by gcc (not needed because of non-ill-conceived design?). However, you might still want to add -mthreads and the static linking options to the build so that the GCC threadsafe exception handlers are used.
---
Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why.
>-----Original Message-----
>From: [hidden email] [mailto:sqlite-users-
>[hidden email]] On Behalf Of Richard Hipp
>Sent: Thursday, 2 April, 2015 14:25
>To: General Discussion of SQLite Database
>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck -
>NXCheck - DBCheck
>
>On 4/2/15, Random Coder <[hidden email]> wrote:
>>
>> I'd recommend the SQLite team turn them on for the version of the DLL
>> they distribute, but I'm honestly not sure if there are negative side
>> effects to doing so.
>
>That's not possible, unfortunately, We compile the published DLL
>(the 32-bit DLL at least) with MinGW so that they will work on older
>versions of Windows. If we used a recent MSVC then the resulting DLL
>will not work on WinXP, I am told.
>
>If the published DLL is not to your liking, it is simple to make your
>own. I suggest you do so. You can start with the amalgamated source
>code file "sqlite3.c". All you need is to compile that one file into
>a DLL that the security checker approves of. How hard can that be?
>
>--
>D. Richard Hipp
>[hidden email]
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
HI,
If I may...
On Thu, Apr 2, 2015 at 4:25 PM, Richard Hipp <[hidden email]> wrote:
> On 4/2/15, Random Coder <[hidden email]> wrote:
>>
>> I'd recommend the SQLite team turn them on for the version of the DLL
>> they distribute, but I'm honestly not sure if there are negative side
>> effects to doing so.
>
> That's not possible, unfortunately, We compile the published DLL
> (the 32-bit DLL at least) with MinGW so that they will work on older
> versions of Windows. If we used a recent MSVC then the resulting DLL
> will not work on WinXP, I am told.
That's not true.
Recent version of MSVC has the option which allows it to build the binary
that will be compatible with the older version of Windows. And this is
for MSVC 2012/13.
MSVC 2010 still able to build WinXP binary just fine.
Unfortunately I don't have the reference at hand. Sorry.
>
> If the published DLL is not to your liking, it is simple to make your
> own. I suggest you do so. You can start with the amalgamated source
> code file "sqlite3.c". All you need is to compile that one file into
> a DLL that the security checker approves of. How hard can that be?
Or even better - include this file in the project solution and build the binary
as statically linked with all required options.
That's what statical linking means.
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________
On 4/2/15, Random Coder <[hidden email]> wrote:
>
> I'd recommend the SQLite team turn them on for the version of the DLL
> they distribute, but I'm honestly not sure if there are negative side
> effects to doing so.
That's not possible, unfortunately, We compile the published DLL
(the 32-bit DLL at least) with MinGW so that they will work on older
versions of Windows. If we used a recent MSVC then the resulting DLL
will not work on WinXP, I am told.
If the published DLL is not to your liking, it is simple to make your
own. I suggest you do so. You can start with the amalgamated source
code file "sqlite3.c". All you need is to compile that one file into
a DLL that the security checker approves of. How hard can that be?
--
D. Richard Hipp
[hidden email]
_______________________
On Thu, Apr 2, 2015 at 10:58 AM, <[hidden email]> wrote:
>
> This are basically compiler switches as far as I understand.
>
> I am not a C programmer, so also quite difficult for me to link the library statically.
These tests basically map to the /SAFESEH, /DYNAMICBASE, and /NXCOMPAT
linker flags. Though, as I understand it, passing these tests is
recommended, and not required for Windows 8 certification.
I have a dump of a build of sqlite from a recent internal build. I'm
not connected with the Sqlite project, I just use it, and happen to
turn on these flags in my build environment for other reasons.
https://bucket-1f8c9d86.s3.amazonaws.com/sqlite3.zip
You can either use my DLL, or build your own version of the DLL with
these options enabled.
I'd recommend the SQLite team turn them on for the version of the DLL
they distribute, but I'm honestly not sure if there are negative side
effects to doing so.
_______________________________________________
sqlite-users mailing list
[hidden email]
This are basically compiler switches as far as I understand.
I am not a C programmer, so also quite difficult for me to link the library statically.
This is what I can read about it here:
[ https://msdn.microsoft.com/en-us/library/windows/apps/jj657973.aspx#binscope_2 ](https://msdn.microsoft.com/en-us/library/windows/apps/jj657973.aspx#binscope_2 )
====================
/SafeSEH Exception Handling Protection
Windows App Certification Kit error message: SafeSEHCheck Test failed
An exception handler runs when the app encounters an exceptional condition, such as a divide-by-zero error. Because the address of the exception handler is stored on the stack when a function is called, it could be vulnerable to a buffer overflow attacker if some malicious software were to overwrite the stack.
What to do if your app fails this test
Enable the /SAFESEH option in the linker command when you build your app. This option is on by default in the Release configurations of Visual Studio. Verify this option is enabled in the build instructions for all executable modules in your app.
Remarks
The test is not performed on 64-bit binaries or ARM chipset binaries because they don't store exception handler addresses on the stack.
Data Execution Prevention
Windows App Certification Kit error message: NXCheck Test failed
This test verifies that an app doesn't run code that is stored in a data segment.
What to do if your app fails this test
Enable the /NXCOMPAT option in the linker command when you build your app. This option is on by default in linker versions that support Data Execution Prevention (DEP).
Remarks
We recommend that you test your apps on a DEP-capable CPU and fix any failures you find that result from DEP.
Address Space Layout Randomization
Windows App Certification Kit error message: DBCheck Test failed
Address Space Layout Randomization (ASLR) loads executable images into unpredictable locations in memory, which makes it harder for malicious software that expects a program to be loaded at a certain virtual address to operate predictably. Your app and all components that your app uses must support ASLR.
What to do if your app fails this test
Enable the /DYNAMICBASE option in the linker command when you build your app. Verify that all modules that your app uses also use this linker option.
Remarks
Normally, ASLR doesn't affect performance. But in some scenarios there is a slight performance improvement on 32-bit systems. It is possible that performance could degrade in a highly congested system that have many images loaded in many different memory locations.
This test is performed on only apps written in managed code, such as by using C# or .NET Framework.
Best regards,
Maarten MOSTERT,
> "Richard Hipp" <[hidden email]> |
> On 4/2/15, [hidden email]
> <[hidden email]> wrote:
> >
> > WARNING
> > Binary analyzer
> > Warning: The binary analyzer test detected the following errors:
> > File C:\Program Files\StakePoint\sqlite3.dll has failed the NXCheck check.
> > File C:\Program Files\StakePoint\sqlite3.dll has failed the DBCheck check.
> > File C:\Program Files\StakePoint\sqlite3.dll has failed the SafeSEHCheck
> > check.
> >
>
> I have no idea what the above means.
>
> Can you work around it by statically linking SQLite into your
> application, rather than using a separate DLL?
> --
> D. Richard Hipp
> [hidden email]
Locked
