Hi. I’m Farid.

I like to share some (sysadmin) stuff here.

Google Chrome unresponsive on terminal server / Citrix XenApp

Like posted before I’m distributing icons from the Windows Group Policy. Citrix has posted a CTX article about this issue, as from version 24 Google Chrome becomes unresponsive and will freeze a lot when you don’t have a GPU. As the article states it’s due it uses the Microsoft RemoteApp technology: http://support.citrix.com/article/CTX132057

I’m seeing these issues too as I publish Google Chrome from the XenApp desktop; Google Chrome will freeze, high memory and CPU usage, corrupted profiles and processes being helt active even after killing the whole chrome.exe process.

Looking into Google Chrome and their forum it seems that Google Chrome is very unstable from version 36 in general, a lot of people are complainting about issues like mentioned above. So what if I use the methods for solving these issues from the Citrix CTX article? Will it help?

When distributing icons through the policy you can use these Chromium flags (http://peter.sh/experiments/chromium-command-line-switches/) for disabling the GPU, disabling PepperFlash and disabling the sandbox.

The command you can give within the icon shall be:

--allow-no-sandbox-job --disable-gpu --disable-bundled-ppapi-flash

Great, when a user is entering the XenApp desktop and opens Google Chrome you’ll see Google Chrome is opening with these flags, also the performance will be better on the Citrix server. Nice job….. BUT…… what if a user opens a new window from within Google Chrome? The flags are not being used, just because it opens the new Google Chrome window without the flags:

If you open the taskmanager you’ll see Google Chrome being opened from the icon with the correct flags, but also that the user opened a few new windows from Google Chrome and have the flags —type=gpu-process:

Now I sorted out a few registry keys which you can import (.XML) so all the Google Chrome sessions will open all with the flags mentioned above. Also the Google Chrome will be the default browser in the XenApp desktop:

<Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Google Chrome Default Browser" changed="2015-03-03 13:56:19" uid="{5295C641-B1D3-46ED-B1E5-8D80C813AA87}" disabled="0" userContext="1" bypassErrors="1"><Filters><FilterGroup bool="AND" not="0" name="Groupname" sid="S-1-5-21-2147495179-3017276484-3716729273-24238" userContext="1" primaryGroup="0" localGroup="0"/></Filters><Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="DefaultIcon" status="(Default)" image="7" changed="2015-01-20 08:20:32" uid="{64FE3A12-DDE5-4945-B7FE-309F303E9B3F}"><Properties action="U" displayDecimal="0" default="1" hive="HKEY_CURRENT_USER" key="Software\Classes\http\DefaultIcon" name="" type="REG_SZ" value="D:\\Program Files (x86)\\Google Chrome\\chrome.exe,0"/></Registry>
    <Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="command" status="(Default)" image="7" changed="2015-02-05 10:07:33" uid="{F3C1DE00-52BD-460B-BAC7-C80C9C50FAEF}"><Properties action="U" displayDecimal="0" default="1" hive="HKEY_CURRENT_USER" key="Software\Classes\http\shell\open\command" name="" type="REG_SZ" value="&quot;D:\Program Files (x86)\Google Chrome\chrome.exe&quot; --disable-gpu --allow-no-sandbox-job --disable-bundled-ppapi-flash %1"/></Registry>
    <Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="DefaultIcon" status="(Default)" image="7" changed="2015-01-20 08:20:49" uid="{E5BBADDF-E726-4360-AA2F-11D23CFE4CCF}"><Properties action="U" displayDecimal="0" default="1" hive="HKEY_CURRENT_USER" key="Software\Classes\https\DefaultIcon" name="" type="REG_SZ" value="D:\\Program Files (x86)\\Google Chrome\\chrome.exe,0"/></Registry>
    <Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="command" status="(Default)" image="7" changed="2015-02-05 10:06:56" uid="{71F814F1-7115-46BE-9123-B4A6262A5670}"><Properties action="U" displayDecimal="0" default="1" hive="HKEY_CURRENT_USER" key="Software\Classes\https\shell\open\command" name="" type="REG_SZ" value="&quot;D:\Program Files (x86)\Google Chrome\chrome.exe&quot; --disable-gpu --allow-no-sandbox-job --disable-bundled-ppapi-flash %1"/></Registry>

Right, and now? You’ll see no more —type=gpu-process enabled chrome.exe processes:

SSLv3 protocol vulnerability ‘Poodle’

Google has announced the discovery of a protocol vulnerability in SSLv3. This vulnerability allows an attacker to read contents of connections secured by SSLv3.

See full Google information here

SSLv3 is a Transport Layer Security (TLS) protocol that has been ratified in 1996. TLS is used to encrypt communications between clients and servers. It is usually integrated with webservers, mailservers or other software that use secure communications.

SSLv3 has been succeeded by TLS v1.0 in 1999 and later by TLS v1.1 and v1.2 in 2006 and 2008 respectively. SSLv3 is still supported on most of the servers for compatibility with clients that have no TLS support such as IE6 on older Windows XP machines for example.

What is it? (Technical)

An attacker can perform a man-in-the-middle attack on SSLv3. This is dependable on a few mitigation factors:

  • Make sure the client and server agree on using SSLv3
  • Exploit vulnerabilities in SSLv3 to obtain (plaintext) traffic
  • The attacker must make several hundred HTTPS requests before the attack could be successful.
  • TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.

The vulnerability has been explained perfectly as CVE 2014-3566 on these websites:

Is my environment affected?

All software supporting SSLv3 is affected by CVE 2014-3566. To see if your servers support the SSLv3 protocol you can use several (online) tools:

You can even use OpenSSL to handshake and check whether your server is using SSLv3. See an example here:

openssl s_client -ssl3 -connect [host]:[port]

Or with Nmap:

nmap --script ssl-enum-ciphers -p [port] [host] |grep "SSLv3: No supported" ||echo "Site vulnerable to poodle"

To give you an idea of the numbers of servers that are vulnerable please see this image – quite a lot:

What can be done on servers?

Disable the SSLv3 protocol on your servers. You can use this document if needed.

Please note that disabling SSLv3 on your servers could impact older operating systems and clients, such as Internet Explorer 6 users on Windows XP.

Instructions for disabling SSLv3 on Nginx and Apache can be found here.

If for some reason that is not possible, Google recommends supporting TLS_FALLBACK_SCSV, which prevents downgrade attacks. Yesterday, OpenSSL released a patch that adds support for TLS_FALLBACK_SCSV.

And about the browser?

As for the browser please note again some websites could stop working due the support for SSLv3. Change the following regkeys/settings –>

Internet Explorer (change in registry):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] "Enabled"=dword:00000000

Mozilla Firefox (about:config)

Set security.tls.version.min 1

Google Chrome (command line)


Mozilla Firefox announced that it has fixed the Poodle vulnerability in the latest build 34, best for Mozilla Firefox users will be to update.


Fox-IT has made a SNORT IDS signature to detect SSLv3 in your network, you can find it on their blog or use this (very useful thanks):

alert tcp $HOME_NET 443 -> any any (msg:"FOX-SRT - SSLv3 Server Hello Detected (Poodle)"; flow:established,to_client; ssl_version:sslv3; ssl_state:server_hello; content:"|16 03 00|"; depth:3; threshold: type limit, track by_src, seconds 300, count 1; reference:cve,2014-3566; classtype:policy-violation; reference:url,http://blog.fox-it.com/2014/10/15/poodle/; sid:1; rev:1;)

Bashbug: Remote code execution through bash (CVE-2014-6271)

Today some big news about a flaw that was found in the way Bash evaluated certain specially crafted environment variables by Redhat.

See for more information here:

An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue. This is OS wide even on Mac OSX.

Is it bad?

OMFG YES THE INTERNET HAS STOPPED WORKING LULLZZ!!!111. No not really, the vulnerability looks pretty awful at a glance, but most systems with bash installed will not be remotely exploitable as a result of this issue. In order to exploit this flaw, an attacker would need the ability to send a malicious environment variable to a program interacting with the network and this program would have to be implemented in bash, or spawn a sub-command using bash. My link to the Red Hat blog post goes into detail on the conditions required for an attack. But please do not underestimate the impact of this bug. It is a problem. Period.

As a result, this vulnerability is exposed in many contexts, for example:

  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
  • PHP scripts executed with mod_php are not affected even if they spawn subshells.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Fix the vulnerability

But how can you know whether you’re vulnerable or not?
Enter the following in a terminal or command shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

And you see this? Then you’re vulnerable.

After updating to the new release 4.3.024-1 (for Example on ArchLinux on my host system) you’ll see an error that means it cannot execute the shell command anymore:

Hereby some command for different distro’s how to fix this issue. But beware, the patch is incomplete, if will not cover up the whole bug:

  • CentOS: yum update bash
  • Ubuntu/Debian: sudo apt-get update && sudo apt-get install bash
  • FreeBSD: sudo pkg update (patched version not available on time of writing)
  • ArchLinux: pacman -S bash
  • Fedora: su -c yum update bash
  • OpenBSD: sudo pkg_add -i -v bash

Anyother way of mitigating this bug (when patching isn’t possible) is by manually compiling bash_ld_preload.c, but this has been tested very limited and might cause issues. Checkout this URL: https://access.redhat.com/node/1200223

Many online testingtools are popping up on the internet, Erratec has started a mass IP-address scan to check percentages of vulnerable systems. Exploits in the wild are also being posted at this moment. Even later today you can expect a module for Metasploit too ;). Good day.

Workaround OpenShift using CNAME and MX records

As stated before I dig the Cloud Application Platform (PaaS) by Red Hat a lot. Same goes for Heroku but they all have a common disavantage: you can’t assign an IP address to your cart(s). That might let you run into issues when you need to configure DNS and MX records.


On the OpenShift website you can read how to configure your DNS to use OpenShift but in my case, after adding a CNAME-record on my rootdomain techswag.nl my MX records stopped being valid. That’s a normal thing, because after you change your rootdomain MX records can’t be validated anymore. But I don’t want to have a subdomain, so what now?

This is NOT going to work:


Tried a lot of possible ways to get this working, even with some help from OpenShift it was still kind of difficult because it depends on what your DNS provider allows you to change. Do they have a redirecting feature? Can you add CNAME records?

Just delete all the unnecessary entries and make a CNAME record that redirects the www.domain.xxx to the OpenShift cartridge. And now redirect all the trafic from *.domain.xxx to http://www.domain.xxx (but note that not all the DNS providers allow this):

How to decrypt SSL and TLS traffic from Citrix Netscaler with Wireshark


In Wireshark, the SSL dissector is fully functional and supports advanced features such as decryption of SSL, but only if the encryption key is provided.

This is useful when troubleshooting Citrix products that use SSL or TLS encryption, in my example to troubleshoot issues with StoreFront. Make sure to understand what SSL certificates you need.

As for troubleshooting you might not want to provide others your priv_key of your certificate, there are 2 methods (one for handing out to 3rd party/support and one for your own – last one will be explained here).


First of all you need to make sure you have a trace which is readable in Wireshark, Citrix has an article about how to do this (CTX120941).


Wireshark can decrypt SSL traffic provided that you have the private key. The private key has to be in a decrypted PKCS#8 PEM (RSA) format. If it is in binary, then it is likely to be in a DER format, which cannot be used in Wireshark.

You can use OpenSSL to convert the key. For example, converting a PKCS#8 DER key to a decrypted PKCS#8 PEM format (RSA) key, enter the following command:

openssl pkcs8 -nocrypt -in der.key -informat DER -out pem.key -outformat PEM
  • der.key is the file name and path to the DER key file
  • pem.key is the file name and path to the PEM key file output

Decrypted PKCS#8 PEM format (RSA) key must be similar to the following screen shot:


Start Wireshark and open the network capture (encrypted SSL should be similar to the following screen shot):

From the menu, go to Edit > Preferences:

Expand Protocols in the Preferences window:

Scroll down and select SSL:

Type the following information in the RSA keys list field, in the format:


Note: IP address of the server/appliance with the private key usually 443 for SSL/TLS usually HTTP <key_file_name> is the location + file name of the private key

There are no spaces between the commas. Also, using semicolons to separate the entries, a list of private RSA keys can be entered and used for decryption if you need to decrypt more than 1 key:


Now type a location and file name for a debug file in the SSL debug file field. Decrypt the SSL traffic (decrypted SSL should be similar to the following screen shot):

For more information about OpenSSL and Wireshark: