@riel	ok people, it's time for our next presentation
@riel	held by Seth Arnold, who works for Immunix, Inc
@riel	his company sells an extra secure Linux distribution, also called Immunix
@riel	Seth will give a presentation on CryptoMark2
@riel	from the description I guess it is a way to make sure the kernel will refuse to run applications that are not trusted ... but since I don't know for sure I'll just sit here and will see what Seth has to say
@riel	sarnold ... the channel is all yours ;)
@sarnold	thanks riel :)
@riel	as usual, if you have questions during the lecture, please ask them in #qc
@sarnold	i'd like to mention that questions and comments should be directed to #qc
@sarnold	feel free to ask them throughout, as I'd like this to be interactive
@sarnold	ther may also be translations to spanish in #redes, depending on translator availability
@sarnold	riel has the gist of cryptomark correct :) we have created a kernel module that will enforce cryptographic signatures on ELF executables
@sarnold	there are several reasons why one would want this:
@sarnold	the first is to help prevent trojan horses
@sarnold	a trojan horse is a program that appears to be useful, helpful, or cute
@sarnold	but is in reality, malicious
@sarnold	the second reason is to help prevent the installation of 'rootkit' programs
@sarnold	typically, when an attacker has cracked a machine, he or she will install a 'rootkit', which will fake the status of the machine to the system administrator
@sarnold	these rootkits are typically binary programs, or compiled on the hacked machine, so preventing them from running would make an attacker's job that much more difficult
@sarnold	you may have heard about "tripwire", which performs a similar job to cryptomark;
@sarnold	however, tripwire is not real time -- it finds a file change some time after the file may have been used
@sarnold	cryptomark tries to fill that time gap by providing instant checks on executables -- when they are run, their signature is checked.
@sarnold	if the signature doesn't work, the executable can't run.
@sarnold	so, onto the signatures :)
@sarnold	what we've done is use a cryptographic hash to provide a unique "fingerprint" of the executable file
@sarnold	then we sign the hash using a public key cryptographic algorithm
@sarnold	and store the signature in an ELF section in the executable
@sarnold	we have chosen to use md5 for the hash function
@sarnold	md5 has been in use, and studied by the community, for many years.
@sarnold	md5 produces a hash value that is 128 bits long, no matter the size of the input document.
@sarnold	the hash looks something like this, when printed in hex: 8e783ec353dcef2db142433465c57ba6
@sarnold	(a notice to newcomers: questions and comments can be asked in #qc at any time)
@sarnold	(español en #redes)
@sarnold	we cannot just use the md5sum tool that comes with most linux distributions, however
@sarnold	because we embed the signature in the executable, as a new ELF section, embedding the signature changes the md5sum of the file!
@sarnold	so, we've written a new tool to compute the hash value on only certain ELF sections, disregarding the signature that we add
@sarnold	we also include in the hash the ELF header, because that specifies the starting address of the executable
@sarnold	(for those who are unfamiliar with ELF, it is simply the structure of binary executable files on modern linux sysmtes, and many unix systems.)
@sarnold	morbo asks: Does cryptomark cover modifications to other elf header sections. (i.e. does it check everything except the embedded md5 checksum?)
@sarnold	Morbo: we include everything that is marked as loadable in the ELF section table
@sarnold	Morbo: in other words, the sections that are likely to effect execution
@sarnold	riel asks: "if the executables are signed with md5, what's to prevent a cracker from md5-signing his own executables before installing them ?
@sarnold	riel: that is the other half of the cryptomark project ;)
@sarnold	we "sign" the hash with a public key cryptographic algorithm
@sarnold	public key crypto systems separate keys into "public" and "private" portions
@sarnold	traditionally, knowing the key of a crypto system is enough to encrypt or decrypt
@sarnold	public key systems allow signatures to be computed. The signature is computed with: the hash, and the private key
@sarnold	-anyone- in possession of the public portion of the key can verify the signature was made with the private portion of the key
@sarnold	in theory, any public key cryptosystem could be used; so far, all public key crypto is number theory too complex to get into here. :)
@sarnold	jose_n asks if the sections we've skipped in the hash computation are "writable"
@sarnold	whether or not the sections are writable relies on the performance of traditional unix access control
@sarnold	marking ELF sections writable or not requires good behavior on whoever would modify the executable
@sarnold	cryptomark is working with the assumption that root control has been "lost" on the machine; we are trying to provide as much sanity on the system as possible.
@sarnold	so, we check the signature on what is essentially the complete executable
@sarnold	if the executable has a flaw in it, that would allow it to access data from an ELF section that (a) is writable (b) is not marked "loadable", then yes, it could be used as an attack vector
@sarnold	i'll give xpato a little time to catch up on the translation, and see if anyone else has any questions...
@sarnold	riel asks: "what happens when a rootkit compromises the kernel to bypass the cryptomark subsystem ? ;)"
@sarnold	riel: in that case, the attacker wins
@sarnold	riel: however, at this point, kernel security vulnerabilities appear to be coming at a rate of one every three or four months, so I'm feeling much better about the kernel's security now than I used to. :)
@sarnold	jose_n asks about portability
@sarnold	the -idea- is extremely portable to other operating systems.
@sarnold	maybe even some of the code will be portable to those other operating systems; portions of it are very self-contained
@sarnold	the implementation should be portable to mutliple architectures within linux, however this has not been tested
@sarnold	we've chosen to use rsa for the public key cryptosystem
@sarnold	previous implementations used el gamal, as implemented by gpg, for the signature mechanisms
@sarnold	this was an unfortunate choice, as signature verification with el gamal is roughly twenty times slower than similar-strength signature validations with rsa
@sarnold	however, at the time, RSA was still patented in the united states, so the decision made a great deal of sense. :)
@sarnold	now that we can freely use RSA, we've switched the implementation to using OpenSSL's rsa_eay implementation. the results are quite a bit faster than the old gpg el gamal implementation
@sarnold	as it is, we've got the key sizes hardcoded to 1024 bits
@sarnold	and there is a check on only one key
@sarnold	adding support for multiple keys (to allow executables to be signed by, e.g., Immunix, Inc. and the computer's owner, or, perhaps, to require multiple signatures before executing a program)
@sarnold	.. is going to take some extra work. it isn't done yet, but it is only a matter of software...
@sarnold	there may be reasons to adding flexibility in the key size support
@sarnold	however, as that provides an extra parameter a potentially malicious user can attack, i'm not sure the gains is worth the extra complexity
@sarnold	and, 1024 bit security is almost certainly sufficient, barring great advances in number theory.
@sarnold	in that case, 2048 or 4096 are likely to be unsafe too...
@sarnold	at this point, you are probably thinking, "gee, isn't 1024 bit multiplications expensive?"
@sarnold	yeah.
@sarnold	luckily, the openssl rsa implementation has been very well optimized over the last several years
@sarnold	in practice, we see slowdown of about 0.2 to 0.3 percent. less than one percent. :)
@sarnold	ijuz says: "therefore we need 64 bit architecture (for faster signature checks)"
@sarnold	ijuz: well, amd's x86-64 has significantly faster crypto performance, but that is likely the result of newly optimized instructions
@sarnold	ijuz: perhaps itanium is or isn't as well optimized..
@sarnold	while we don't have a full implementation available yet, details about an older implemtnation, and news on the new implementation, will be available here: http://www.immunix.org/cryptomark.html
@sarnold	are there any more questions?
@sarnold	have i addressed all asked questions? :)
@sarnold	jose_n asks, "does cryptomark use any caching?"  yes, we do, but we're not positive it is perfect yet.
@sarnold	and riel asks the much more difficult question, "does cryptomark check shared libraries, too ?"
@sarnold	which is related to morbo's question... "Does cryptomark check scripts?"
@sarnold	we currently don't check shared libraries.
@sarnold	checking shared libraries is something that we should do at some point in the future.
@sarnold	however, the usefulness isn't as great as one would like: (a) shared libraries don't have atomic guarantees from the kernel (b) shared libraries can be loaded directly with mmap()!
@sarnold	so, there are many ways that shared libraries can be loaded in such a fashion that it isn't obvious to the kernel
@sarnold	scripts are the same problem: there are far too many ways the script interpreter can load code. mediating them all from the kernel is difficult.
@sarnold	ijuz asks of openssl's license is compatible with the gpl: we're not sure, and thanks for the reminder. :)
@sarnold	F3nix has asked a question, "cuales son los requisitos minimos para cryptomark?"
@sarnold	which I think means, "what are the minimum requirements for cryptomark"
@sarnold	as cryptomark necessarily stomps on demand-paging a little, it helps to have some more ram
@sarnold	and, as cryptomark does difficult operations, it helps to have a fast cpu
@sarnold	however, my test machine is a celeron 400 with 32 megs of RAM, and I like it that way. it forces me to find better solutions.
@sarnold	jose_n suggests that keeping setuid root and compiler statically linked would help .. it would
@sarnold	however, we learned from the zlib fiasco that statically linked (and worse, cut-n-pasted!) code is a serious long-term detriment to maintainable systems
@sarnold	cthulhu_ asks: "what happens when you change code on runtime, with ptrace for example ?"
@sarnold	it helps to recall the threats cryptomark is trying to solve .. it wants to raise the bar for trojan horse injection, and wants to eliminate non-kernel rootkits
@sarnold	since ptrace can modify running processes, and thus is not persistent, ptrace doesn't have much impact on the first
@sarnold	the second, i'm not entirely sure .. i think the non-persistence is again going to help
@sarnold	but, cthulhu_ has a good point, that cryptomark won't solve all your problems :)
@sarnold	ok, last call for questions? :)
@sarnold	ok, then I'd like to thank xpato for doing a great job translating to spanish in #redes, and everyone who asked fantastic questions :)
@sarnold	and a reminder that the next lecture is in four hours, oscar e ruiz bermudez, on "Test of Penetration in a Data Network"
@sarnold	thanks :)

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!