I have the following question about  Windows SSPI. I have made an Win32 app that has to authorize with a  server: using protocol MS-SIPAE in NTLM mode. The app uses SSPI. 
See http://msdn.microsoft.com/en-us/library/cc431510.aspx. about the MS-SIPAE.  There is the following step there (http://msdn.microsoft.com/en-us/library/dd946897.aspx): “The protocol client uses an authentication protocol GSS_GetMIC() call, as specified in [MS-NLMP] section 3.1.4 for NTLM, and in [RFC2743] section 2.3.1 for Kerberos, to generate a signature token for the buffer constructed in the preceding step 2 using the authentication protocol context stored in the SA. ”

The question is: what exactly corresponds to the  abstract “GSS_GetMIC” in SSPI API? In SSPI I have found a function named MakeSignature – seems this is what I need. Also an MSDN article http://msdn.microsoft.com/en-us/library/ms995331.aspx seems to confirm this. Can someone confirm this conclusion (I do not want rely on the ‘seems’ )?


Question: How does arbitary code execution work?
Answer: Code injection / Code execution is any attack that involves tricking a node in a distributed system into running code specified in a network message that was supposed to be treated as plain text/bytes.

The arbitrary part means that the vulnerability allows the attacker to make use of the full authority of the running process or of some privileged principle like root.




  given that modern OSes implement DEP and ASLR, how is this even feasible


Code injection relies on some other kind of vulnerability to inject the payload.  You're probably thinking of injection via buffer overflow but there are other ways to inject code that memory address space tricks don't help against.

Code injection doesn't necessarily mean injecting instructions in the processor's instruction set into a code/data segment.  It can mean injecting source code in a scripting language which the program foolishly interprets.  For example, shell injection involves injecting bytes that are passed to a shell.


  Shell injection (or Command Injection[10])is named after Unix shells, but applies to most systems which allow software to programmatically execute a command line. Typical shell injection-related functions include system(), StartProcess(), and System.Diagnostics.Process.Start().




Some systems have used string tainting * to try to mitigate code injections that aren't covered by DEP/ASLR and it does help but isn't foolproof:  taint bits aren't serialized when strings are serialized to files/DBs and, under maintenance, more untaint instructions are added to a program to fix high visibility non-security bugs than are removed to fix low-visibility security vulnerabilities.


  The concept behind taint checking is that any variable that can be modified by an outside user (for example a variable set by a field in a web form) poses a potential security risk. If that variable is used in an expression that sets a second variable, that second variable is now also suspicious. The taint checking tool proceeds variable by variable until it has a complete list of all variables which are potentially influenced by outside input.




Systems that label strings based on information flow have also been used to secure distributed systems that have to mix strings of different provenance, but information-flow is more of an all-or-nothing approach: harder to retrofit onto systems that were not designed around it.


  Information ﬂow control protects information security
  by constraining how information is transmitted among
  objects and users of various security classes. These security classes are expressed as labels associated with the information or its containers.


Taint-checking, above, is a very simple kind of information flow analysis in which the labels are restricted to (tainted, untainted).