The async transport option is broken by design.
If used the main loop is called from the transport thread and the
main thread of the application.
Unless the transport layer is refactored to just work on queues
(input and output) this option will never work, therefore remove it.
This option will ensure that NLA is disabled(since NTLM uses weak crypto algorithms), FIPS
encryption is enabled, and ensure fips mode is enabled for openssl.
Selectively override specific uses of MD5/RC4 with new API calls specifically tailored to override FIPS.
Add comments on why overriding the use of these algorithms under FIPS is acceptable for the locations where overrides happen.
Remove check of server proprietary certificate which was already being ignore to avoid use of MD5.
Initialize winpr openssl earlier to ensure fips mode is set before starting using any crypto algorithms.
If the size parameter is used with a percentages like /size:50% now
an additional 'w' or 'h' can be appended (like /size:50%w) to specify
where the percentage should be applied. If both or none are set the
behavior is like it was before and the percentage is applied to width
and height.
SSL functions like OpenSSL_add_all_digests should be invoked at very beginning as they are not MT safe.
If not we might meet double free exception as following:
#0 0x00007f23ddd71c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f23ddd75028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f23dddae2a4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007f23dddba55e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f23dc6ecfcd in CRYPTO_free () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#5 0x00007f23dc6ef8d1 in OBJ_NAME_add () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#6 0x00007f23dc77dcd8 in EVP_add_digest () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#7 0x00007f23dc782321 in OpenSSL_add_all_digests () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#8 0x00007f23c781da28 in winpr_openssl_get_evp_md (md=4) at /home/zihao/workspace/zihao_FreeRDP/winpr/libwinpr/crypto/hash.c:52
#9 0x00007f23c781dccb in winpr_Digest_Init (ctx=0x7f22d064d470, md=<optimized out>) at /home/zihao/workspace/zihao_FreeRDP/winpr/libwinpr/crypto/hash.c:344
#10 0x00007f23d486139b in security_salted_mac_signature (rdp=0x7f23859f5a20, data=0x7f238542d4fb "\004\204\022\004", length=4743, encryption=<optimized out>, output=0x7
at /home/zihao/workspace/zihao_FreeRDP/libfreerdp/core/security.c:378
#11 0x00007f23d488d73f in fastpath_send_update_pdu (fastpath=<optimized out>, updateCode=4 '\004', s=0x7f23859f5f40, skipCompression=true)
at /home/zihao/workspace/zihao_FreeRDP/libfreerdp/core/fastpath.c:1076
#12 0x00007f23d4891c4f in update_send_surface_frame_bits (context=0x7f23859f5540, cmd=0x7f22b2ffcc80, first=true, last=true, frameId=6)
at /home/zihao/workspace/zihao_FreeRDP/libfreerdp/core/update.c:1041
Related reports: https://rt.openssl.org/Ticket/Display.html?id=2216&user=guest&pass=guest
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
If a target is linked against libraries with cmake
(target_link_libraries) and the libraries are not marked as PRIVATE
they are "exported" and in case a other target is linked against this
target it is also linked against *all* (not private) libraries.
Without declaring private libraries PRIVATE a lot of over linking
(linking against unneeded libraries) was done.
Sometime it's possible that your server application doesn't have access to files
(when running in a very restricted environment for example). This patch allows
to ship the private key and certificate as a string.
Sponsored by: Wheel Systems (http://www.wheelsystems.com)
build-config.h should contain configure/compile time settings that are
relevant for projects that use FreeRDP.
For example the compiled in plugin search paths.
This patch contains:
* checks for malloc return value + treat callers;
* modified malloc() + ZeroMemory() to calloc();
* misc fixes of micro errors seen during the code audit:
** some invalid checks in gcc.c, also there were some possible
integer overflow. This is interesting because at the end the data are parsed
and freed directly, so it's a vulnerability in some kind of dead code (at least
useless);
** fixed usage of GetComputerNameExA with just one call, when 2 were used
in misc places. According to MSDN GetComputerNameA() is supposed to return
an error when called with NULL;
** there were a bug in the command line parsing of shadow;
** in freerdp_dynamic_channel_collection_add() the size of array was multiplied
by 4 instead of 2 on resize
Command line detection is run with dummy settings where not everything
is allocated. Collections (device, dynamic channel and static
channel) didn't handle this case properly.
[MS-RDPBCGR] Section 5.3 describes the encryption level and method values for
standard RDP security.
Looking at the current usage of these values in the FreeRDP code gives me
reason to believe that there is a certain lack of understanding of how these
values should be handled.
The encryption level is only configured on the server side in the "Encryption
Level" setting found in the Remote Desktop Session Host Configuration RDP-Tcp
properties dialog and this value is never transferred from the client to the
server over the wire.
The possible options are "None", "Low", "Client Compatible", "High" and
"FIPS Compliant". The client receices this value in the Server Security Data
block (TS_UD_SC_SEC1), probably only for informational purposes and maybe to
give the client the possibility to verify if the server's decision for the
encryption method confirms to the server's encryption level.
The possible encryption methods are "NONE", "40BIT", "56BIT", "128BIT" and
"FIPS" and the RDP client advertises the ones it supports to the server in the
Client Security Data block (TS_UD_CS_SEC).
The server's configured encryption level value restricts the possible final
encryption method.
Something that I was not able to find in the documentation is the priority
level of the individual encryption methods based on which the server makes its
final method decision if there are several options.
My analysis with Windows Servers reveiled that the order is 128, 56, 40, FIPS.
The server only chooses FIPS if the level is "FIPS Comliant" or if it is the
only method advertised by the client.
Bottom line:
* FreeRDP's client side does not need to set settings->EncryptionLevel
(which was done quite frequently).
* FreeRDP's server side does not have to set the supported encryption methods
list in settings->EncryptionMethods
Changes in this commit:
Removed unnecessary/confusing changes of EncryptionLevel/Methods settings
Refactor settings->DisableEncryption
* This value actually means "Advanced RDP Encryption (NLA/TLS) is NOT used"
* The old name caused lots of confusion among developers
* Renamed it to "UseRdpSecurityLayer" (the compare logic stays untouched)
Any client's setting of settings->EncryptionMethods were annihilated
* All clients "want" to set all supported methods
* Some clients forgot 56bit because 56bit was not supported at the time the
code was written
* settings->EncryptionMethods was overwritten anyways in nego_connect()
* Removed all client side settings of settings->EncryptionMethods
The default is "None" (0)
* Changed nego_connect() to advertise all supported methods if
settings->EncryptionMethods is 0 (None)
* Added a commandline option /encryption-methods:comma separated list of the
values "40", "56", "128", "FIPS". E.g. /encryption-methods:56,128
* Print warning if server chooses non-advertised method
Verify received level and method in client's gcc_read_server_security_data
* Only accept valid/known encryption methods
* Verify encryption level/method combinations according to MS-RDPBCGR 5.3.2
Server implementations can now set settings->EncryptionLevel
* The default for settings->EncryptionLevel is 0 (None)
* nego_send_negotiation_response() changes it to ClientCompatible in that case
* default to ClientCompatible if the server implementation set an invalid level
Fix server's gcc_write_server_security_data
* Verify server encryption level value set by server implementations
* Choose rdp encryption method based on level and supported client methods
* Moved FIPS to the lowest priority (only used if other methods are possible)
Updated sample server
* Support RDP Security (RdpKeyFile was not set)
* Added commented sample code for setting the security level
"libfreerdp" consisted of multiple (small) single libraries. If the cmake
option MONOLITHIC was used only one library was build combining all of
the libfreerdp-* libraries.
The only exceptions to this are libfreerdp-server and libfreerdp-client these
are build as separate libraries.
This commit obsoltes non-monolithic builds and makes monolithic builds
the default. The cmake option MONOLITHIC is also removed.
winpr is now always build as single library.
The build option MONOLITHIC_BUILD doesn't influence this behavior anymore.
The only exception is winpr-makecert-tool which is still build as extra
library.
This obsoletes complex_libraries for winpr.
# By Marc-André Moreau (20) and others
# Via Mike McDonald (6) and others
* 'master' of git://github.com/awakecoding/FreeRDP: (26 commits)
libfreerdp-codec: fix C++ headers
libfreerdp-codec: fix ClearCodec short vbar cache hit
libfreerdp-codec: improve ClearCodec error checking
libfreerdp-codec: fix ClearCodec RLEX decoding
libfreerdp-codec: ClearCodec fix error codes and wrapping around of cursors
libfreerdp-codec: fix some ClearCodec flag checking
Fixed issue with last merge.
Added #ifdef WITH_OPENH264 ... #endif to appropriate places in the code.
libfreerdp-codec: handle long vbar length mismatch
channels/rdpgfx: add egfx command line options and settings
libfreerdp-codec: reduce number of variables
libfreerdp-codec: improve ClearCodec robustness
libfreerdp-codec: simplify ClearCodec code
Initial implementation of H.264 decoder for MS-RDPEGFX
libfreerdp-codec: improve ClearCodec subcodec xStart, yStart handling
libfreerdp-codec: improve ClearCodec subcodec support
libfreerdp-codec: improve ClearCodec error checking
libfreerdp-codec: more ClearCodec vBar caching
channels/rdpgfx: harden parsing code
libfreerdp-codec: add ClearCodec glyph cache
...
