Compiling libssh in Visual Studio 2017

I've decided to do a small write up on compiling libssh with Visual Studio 2017. It took me a little bit to get it working and there are no walk-throughs or tutorials online as far as I can tell. I saw quite a few people asking on forums and email archives on how to do this. I am typically a Linux user, so I don't have too much experience compiling in VS/Windows. Hopefully this will help someone that was stuck like I was!

So first thing is download the version of libssh you need from https://www.libssh.org/files/ . In my case I am using version 0.8.5.

You will also need to install Openssl. I used a precompiled binary from here: https://indy.fulgan.com/SSL/ . Installation is straightforward. Also, zlib is optional while compiling libssh. I did not include it as I didn't need it. Cmake is also required if you do not have it installed already. 

Extract the tarball into whatever directory you want it in. In my case I extracted it into C:/libs/libssh-0.8.5 . Create an empty directory to generate the build files into. For the sake of simplicity I just chose C:/libs/libssh-0.8.5/output . 

When you open Cmake, set the source code location to C:/<path>/libssh-0.8.5/ and the output location to wherever you created your output directory. 

Now click "Configure". You will be asked to choose the version of Visual Studio you are using. 

Click finish. Cmake will do it's thing for a bit. If you did NOT install zlib like I did, you will get this error. I think this is where most people are getting stuck. In the forums I saw, people were complaining about this.

Just scroll through the entries in the list and uncheck "WITH_ZLIB". The only reason I compiled this without zlib was that I was just working on a small personal project and didn't see a reason to include it.

When Cmake is done, the contents of your output directory should be full of the appropriate directories, files, VC++ Projects and "libssh.sln". Open the solution in Visual Studio. It should include these projects:

Build it via Build->Build Solution or (Crtl+Shift+B). The resulting .dll, .exp and .lib files will be located in your output directory in C:/<output path>/src/release . 

In hindsight this was incredibly simple, so I'm not sure why I had trouble with it. I think the people in the forums/emails I saw were trying to generate the build files in the wrong directory with Cmake. I was having problems getting it to build in VS, but that was probably my lack of experience with it. Anyways, hope this helped someone!   

CTS Labs AMD Flaws Announcement and amdflaws.com

So like everyone else in the InfoSec world at the moment, I am not amused with the recent whitepaper released by CTS Labs and its accompanying website: https://amdflaws.com/

In my opinion, this will go down as a huge blunder on CTS Labs part. After reading the terribly written whitepaper, I am thoroughly convinced that this is nothing more than an attempt at gaining notoriety via fear mongering and over-hype. They only gave AMD a 24-hour notice before releasing this by the way. Also, nobody seems to know who CTS Labs is.

https://safefirmware.com/amdflaws_whitepaper.pdf

The are four flaws being marketed are:

• RYZENFALL
• MASTERKEY
• FALLOUT
• CHIMERA 

First of all, I would like to point out that I'm sick of these stupid vulnerability names with matching logos. Marketing like this has no place in InfoSec as far as I'm concerned. My problem with this whole situation isn't with the vulnerabilities themselves, but with how this new information is being handled by CTS Labs. 

Anyways, on to the vulnerabilities. 

Here's a clip of the whitepaper regarding RYZENFALL:

Ok, so here's the thing. Yes, this vulnerability exists. Is it plausible that the average person will be at risk to this happening on their system? Not in the least. Not only will the computer have to be fully compromised, the attacker will also have to use a vendor supplied driver to execute this, specifically on a Ryzen chip (FALLOUT, CHIMERA have the same requirements for exploitation, but on different chipsets). Its all about threat modelling. This doesn't deserve the hype they are trying to push.

Here's my favorite clip from the whitepaper regarding MASTERKEY:

Really? If someone is flashing my BIOS with a custom ROM, there is a bigger problem at hand. Again, this does not deserve the hype they want.  

The main problem with all this is the manner in which this is being handled by CTS Labs. They are attempting make it seem worse than it is by trying to create enough noise and scare people who don't understand. Which is a reprehensible act on their part. The fact that these vulns require elevated admin access before exploitation can even be attempted, immediately reduces their severity. Yes they do exist, but they are not an impending immediate threat. Some people are even calling them pseudo-vulnerabilities. However I will not. 

In the end, I think it is our responsibility as community to handle these situations with professionalism and rationality, and this is a prime example of the opposite. One thing I am happy about is the amount of people calling out CTS. They deserve it and I hope it deters other "Labs" from doing this.