Questions about the result of an external test

[Sherlock 659]

So, my application has been tested by an external company to check for vulnerabilities. This test was part of a larger audit of our company. I have one or two questions about this test especially concerning Delphi and its possibilities. The application is an FMX Win64 app, that tries to connect to dedicated servers in the local net, these must be configured in an ini-file accordingly. The app produces no sound, just charts or other imagery. No here are the test results in my own words. What I would like to know is how to avoid them in the future.

1. It was observed that the app allowed the loading of an insecure DLL. Namely avrt.dll. The App uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.
2. It was observed that the app has the following compilation flags not enabled/ not set.
   - Authenticode
   - cfg
   - forceIntegrity
   - gs
   - rfg

As for 1) that seems to be some audio or multimedia thingy according to https://windows10dll.nirsoft.net/avrt_dll.html. As I wrote before: No sounds from my App. How can I shut this down?

I am at a total loss concerning 2). I wouldn't even know where to start looking for those flags. Is anyone here aware of a problem with 2)? And who knows how to fix that?

[Der schöne Günther 312]

You may be able to use tools like "Dependency Walker" to find out which dependency includes avrt.dll. I wouldn't be surprised, however, if that's straight from the VCL.

 

The flags in (2) seem to be PE header flags in your executable. I wouldn't even be surprised if half of them are some "Visual Studio only" flags by Microsofts Linking executables.

 

Can't the auditor be a little more helpful and provide some context? 

 

[Kas Ob. 117]

1 hour ago, Sherlock said:

- Authenticode
- cfg
- forceIntegrity
- gs
- rfg

This made laugh and angry at the same time, along with audit in the same post.

 

Anyways, don't have time, to write a lot, but later will post about this and give you some rest.

 

Meanwhile, convert and build your application to Visual Studio from a company called Microsoft to pass these flags, which are not named as they should.

[Kas Ob. 117]

2 hours ago, Sherlock said:

It was observed that the app allowed the loading of an insecure DLL. Namely avrt.dll. The App uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.

I have no idea why this DLL is imported, but searching landed me here 

https://learn.microsoft.com/en-us/windows/win32/api/avrt/

 

And those belongs to https://learn.microsoft.com/en-us/windows/win32/procthread/multimedia-class-scheduler-service 

Nothing more about this, except some little rant about how Delphi RTL and VCL using and importing stuff just because the original designer didn't think it through, useless stuff, like every single Delphi application is importing winspool.drv for no reason at all except the idea that every application should use the printer !! and historically the Printer Drivers were the most abused for security vulnerabilities, hence just adding more stuff to irritate any AV about Delphi applications,

also there is this one "winsta.dll" which as i recall were used as backup in case the application can't figure the OS version, so there is a static import for this DLL and it is not call, this DLL is the library responsible for many terminal and servers (stations) connection and licenses managing, communicating... etc , this one is red flag for any application in the eyes of any Security software (AV)...

enough of that.

 

3 hours ago, Sherlock said:

It was observed that the app has the following compilation flags not enabled/ not set.
- Authenticode
- cfg
- forceIntegrity
- gs
- rfg

I think you can't do any of these in Delphi except this one "Authenticode", which has nothing to do with the compiler or linker, this is not even a flag, this is the Digital Signature as defined by Microsoft, so all you have to pass this, is to sign you binaries with Code Signing Certificate issued by trusted Certificate Authority that leads to trusted root in the OS store (certificate store).

 

The rest names decryption :

cfg = Code Flow Guard , Delphi compiler can't produce compatible code for this, in fact i don't any other compiler than VS will do it, as the whole CFG is not yet matured, and really should depend on specific hardware, namely CPU features, this is new standard. to read more about this 

https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf

 

forceIntegrity = https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170 well this one is complete useless and will not add any security what so ever, easy to enable though as it is a simple bit in the PE header

 

gs =  well this one is tricky as it might be Gs or GS

https://learn.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=msvc-170

https://learn.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=msvc-170

One does need special stack protection explained by stack cookies while the other ensure free buffer zone in the stack, both Delphi can't do !

 

rfg = Return Flow Guard very similar to CFG, also to my knowledge this one is part of CFG, and it is useless to make it out of CFG, and there is no specification yet on how to be implemented except in theory and as VS do it !

https://security.stackexchange.com/questions/206560/methods-of-exploiting-a-windows-executable-protected-by-control-flow-guard-and

 

I hope that explained the whole thing a little for you, also the one who compiled the report for you, adding these together may be didn't understand them fully or what do they means or how they works, it could be one of these great software that do understand security and how it should be implemented (/sarcasm/), in all cases CFG and GS are impossible with Delphi compiler and linker, although GS protection is possible by using EurekaLog, but it will kill the performance of you application, yet they can not see the flag where the OS will do its part, so the protection against the stack/buffer overflow will be there but no one will witness, audit report should be based on actual source and deep understand what it does, yet it might be regulatory thing these days.

 

as for CFG and its RFG, if it is that much needed then you need to redo you application in VS (namely Visual Studio) nothing else.

 

Good luck and hope that was clear.

[Sherlock 659]

@Kas Ob. thank you very much for this really detailed explanation. Very VS-centric. I had feared as much, when I read the report.

 

I would like to know Embarcaderos position on this. This seems to be quite the aggressive attack on non-VS development, thinly veiled by regulatory requirements or the ever so popular "compliance". On the other hand now I have at least a bit of ammunition to react to this peculiar thing.

 

On a side note, this is part of the process to get software certified as a medical device... something that gets harder every day in Europe and easier in the USA.

 

But still, the claim or issue remains, that Delphi applications might load some DLL from insecure places. Without the developers intent. I found what caused the avrt.dll to load BTW. In my case it was the unused inclusion of the unit FMX.Media....

[Kas Ob. 117]

2 hours ago, Sherlock said:

I would like to know Embarcaderos position on this.

I wouldn't expect much on/from this, for many years i am not fan of what Embarcadero focusing their effort and resources, but about this particular one, i don't think they can do much.

 

Take an example CFG, it is still new and not fully matured by Microsoft itself, while the real deal (the devil most needed) in its parts is RFG, this one in particular is not standardized and i really don't expect they will have any specification any time soon if ever !

Without written specification, no compiler and linker can perform/produce compliant code, a code that OS require to to perform undocumented behavior while still changing on the OS part, so ...

Embarcadero can't help or do much for now, yet there is parts can be implemented, here i am talking about parts to be comply with the known and documented part of the CFG.

 

The request for RFG is outrageous and out of the reality as you mentioned it, even Rust with LLVM can't do it.

 

I expect that audit is more like the more the merrier in a (longer) list of checkboxes without thinking them enough, and it is their right to do so after all, they should everything they can think of, the red line is were to make it a deal breaker.

 

2 hours ago, Sherlock said:

But still, the claim or issue remains, that Delphi applications might load some DLL from insecure places. Without the developers intent. I found what caused the avrt.dll to load BTW. In my case it was the unused inclusion of the unit FMX.Media....

On this i agree, this is Embarcadero lack or lag in this space, they neglected this part for very long time, i mentioned 2 DLLs out of punch i came across and you have one, i had in few projects to remove the import for these two DLLs to raise a project rank in VirusTotal, signed or not signed was it.

But for Embarcadero to do something about this they need put effort and ask for what should be removed or adjusted, the community can report them, of course some public awareness is critical here, so an initiative should be take a place, started by Embarcadero.

 

I am out of touch with the new IDEs, and really don't know if the mentioned above DLLs still relevant now, but many here aware about this now and can help, as for FireMonkey and cross platforms.