Format String Attacks in a non-C/C++ environment

A ton of people are under the impression that format string attacks are only a C/C++ vulnerability (as in, if you code in a different language, you are safe).First, read this article

Second, try this bit of C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace FormatStringsC
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                // if I was a user inputted string you would be in trouble
                String fspec = "{1},{10}";
                Console.Write(fspec, "I don’t know but ", " I’ve been told ");
                // return 0;
            }
            //generic catch all
            catch (Exception e)
            {
                Console.WriteLine("Oops! Shutting down app\n");
            }
        }
    }
}

Third, keep watching this space for examples in other languages

Linux Copy Protection, a first look

While one can see a ton of (mostly not functional ) code protection schemes in the Win32 world, I have not seen that many into Linux. Perhaps it might be due to most software for Linux is open source (and quite good, if I may add) but this is a research area that has been largely neglected.

I am currently working (free time of course, not company related) with a scheme of protecting functions. I took the inspiration from commercial CD protection schemes (SafeDisk, SecureROM, etc). The only requirement I put are these:

1. Superuser access will not be required
2. (kinda obvious from the above): No kernel level stuff

The first approach would be to simply pack (or encrypt and pack if you prefer) the whole binary. This is naive if it is the only layer of protection. Other people have tried it and eventually failed. If there is an automatic unpacker for your packing scheme, then it is trivial. If one dabbled with breaking copy protections from games then he might remember the unsafeDisc wrappers that were all the rage.

My second idea comes from the win32 world and is simple and effective. I will be using the term DLL but feel free to think of shared object (.so) if you are so inclined.

a) Create a .so object with the functions you want encrypted. Test that the unencrypted code works.

b) Encrypt the code using a custom made tool

c) In your code decrypt the .so

d) using dlopen(), load the relevant dll, load the function, call it (say supplying the serial as an argument), store the results or whatever (this is purely POC so far so it just checks for an argument).

e) dlclose(), Free the unencrypted .so from memory.

Some attack vectors off the top of my head:

• What if the user supplies his own .dll? (i.e. overwrite our DLL with his own stub that say always returns true?)
• At least for a while the whole .so will be in memory, if the guy knows where to look (place a breakpoint in dlopen()) and dumps the memory,voila. there is the unencrypted function.
• Tricks as anti-debugger protection, might be useful, but as with packing, they are only there to provide a gimmick, not to really prevent disassembly and patching of our function.
• dlopen expects the name of the function. Perhaps a way must be devised that this is not that trivial for an attacker to obtain? (Use serial as a decrypting key for a string perhaps?)

I have only been working on this one for a few hours at most but somehow I sense this will be a pet project for quite some time to come :). Watch this space for any updates and Merry Xmas y’all.

Simple (insecure) python password generator

Not the best point of my career, much of it is an extension of GPL cookbook code but it may come in quite handy to a few people so I decided to post it here.

# A simple password generator
# not very secure but will do in a pinch as one can
# predict the format of the password and has limited
# entropy but ok  

import string
import random

alpha=6
# numeric includes some symbols as well
numeric=4

digits = string.digits
vowels = ['a','e','o','u','i','y']
consonants = [a for a in string.ascii_lowercase if a not in vowels]
symbols = ['!','@','#','$','%','^','&','*','(',')']
ssymbol = string.join(symbols,'' 
digits += ssymbol

####################################
######### util functions ###########
####################################
def a_part(slen):
  ret = ''
  for i in range(slen):
    if i%2 == 0:
      randid = random.randint(0,len(consonants)-1) #number of consonants
      ret += consonants[randid]
    else:
      randid = random.randint(0,len(vowels)-1)
      ret += vowels[randid]
  return ret

def n_part(slen):
  ret = ''
  for i in range(slen):
    randid = random.randint(0,len(digits)-1)
    ret += digits[randid]
  return ret
####################################
fpl = alpha/2
if alpha % 2 :
  fpl = int(alpha/2) + 1
lpl = alpha - fpl

start = a_part(fpl)
mid = n_part(numeric)
end = a_part(lpl)

print "%s%s%s" % (start,mid,end)

Ruby On Rails real strength

• Faster in development time than J2EE (the claim that a small RoR application can be the size of all XML documents required to work with J2EE is correct)
• Better than PHP (forces you to avoid bad development practices, a case that is seen all too many times)
• YAML
• Cool kid on the block

Other than that, if you are outside DHH’s frame of mind, good luck

Web Application Frameworks to keep an eye on in the future

If you are doing small to medium scale web application development (btw, I do not want to imply that the frameworks  here are unsuitable for large projects, but since I have no personal experience using them in a large project, I will not add a hearsay opinion) you really should keep an eye on these:

1

2

3

4

Which one of them will survive (since there is a ton of Java frameworks, many claim that Ruby is a fad and two frameworks for python?) will depend on many factors, not all relevant with technical excellence or ease of use.

I have the honour to work with #2 to make ends meet and #3 for personal projects. I like them both but the common thing is that innovation is shared (i.e. they have many things in common ) . DRY anyone?

Yet another quick J2ME tip for newbies

While checking the logs I came across “j2me png manipulation”. So, a few tips that you probably have heard before:

• The less, the merrier. If you can combine the images in a single file, you save JAR space.
• Indexed PNGs are your friend. You can do a lot with 256 colors (hell, I grew up on the Amiga 500 that had 32 colors for gaming).  If you have a lot of  black an white graphics, MAYBE you can save some space by combining them  and using indexing and keep your colored ones separate,but this is on a case by case basis.
• Try a few different PNG encoders. Their mileage may vary
• Another bonus is that if you have few (or even better one!) PNG file, you can encrypt it (most of the encryption I have seen is XOR but ok, that will stop the casual thief), decrypt it in memory (which in most Nokia S40 phones is more than you have available for your filespace), hope the garbage collector does its job ( calling gc() does not guarantees execution and you might be a victim of memory fragmentation but most of the time works ok).
• Since reading from the JAR is slow and space is extremely limited anyway, the evident benefit of keeping your assets in a single file (like most PC/console games) is not of concern.
• If the API has extensions for mirroring, by all means use them. Once again, you trade off JAR space over RAM.

Some thoughts about the future of computer security

Here is an extended version of the comment I have made over to EM Blog about bug hunting getting harder and harder and about the future of computer security

- VM Technology

The industry is moving towards a VM enviroment (.Net and Java are two instant examples that spring to mind). If you discover a flaw in say win32 JVM, chances are that it will affect other versions, giving great leverage on the flaw finder (and if he is malicious then one can relieve the era of mass-rooters and other tools of mass destruction). Combined with the hunt for data accessible from web applications, if you “own” the application and steal the data, it is mission complete. (provided the attacker has a clue about covering his tracks).

- Code Quality

Bug classes like format string bugs can be reduced to (almost?) non-existent by the use of automated tools combined with plain old manual checking. The average developer is much more security aware than the average software developer 10 years ago or so (assuming that he has some time to research the security implications of her code and is not constantly rushed by the management). Trivial buffer overflows tend be a thing of the past, but once in a while a ridiculous bug like Solaris telnetd shows the far reaching tentacles of human stupidity (not meant as an insult to Solaris developers who are more skilled than me but come on, this one was plain dumb).

- Open Source.

While open source is not the panacea of software security its advocates would led you to believe (i.e. there are tons of messy, insecure code out there, especially in the lesser projects), it helps security, not only with the usual peer review process, but by EDUCATING programmers. If you want a secure way of doing something, chances are you can find and study some open source code, see what works and what not. If the code is governed by a suitable license, then it can be freely incorporated into your programs (foe example: SecuRom copy protection (a pretty popular protection in the world of win32 games) is incorporating elements of OpenSSL software), saving time and effort.

- Modern Bug Hunter

Considering the above all is not lost for the bug hunter (professional or amateur). Today the average exploit hunter has more tools in his disposal. Imagine having something like Ida Pro back in the early 90s. How many bugs from closed software would have been rooted out? Methodologies for vulnerability discovering are common knowledge. This can work in favor of the attacker (he knows what to look for and how to look for it) and against him (if the developer actually took some time to test the code ). Thus “easy” bugs like the regular BO will become less and less common (again see point in Code Quality about human stupidity for an exception to the rule). A byproduct of this difficulty is that perhaps the dimestore security consultant (something that anti.security.is was against with their NO DISCLOSURE movement) will, if not go away, lessens its impact in the professional security scene and move a bit down the food chain.

Answering the original’s post question, vulnerability research will be here for a long time (I’d wager that since IT moves further and further into the everyday life (i.e. your modern cell phone has more power than some routers ), exploitation techniques will become more difficult over time but the use of tools will offset the effect of , say, kernel level mechanisms so the overall difficulty in the process will remain the same. I believe that there are undiscovered bug classes having yet to be explored and of course the new technologies will bring more bug classes (and perhaps revive old ones, ever heard of the new format string bugs in Java and Python? If not, look it up at Dr Dobbs magazine.).

Feel free to read the original article at EM Blog