FUG-BR / Grupo Brasileiro de Usuarios de FreeBSD

FUG-BR / Grupo Brasileiro de Usuarios de FreeBSD - Links

15.07

Inicio

Links

Principal

RSS / Twitter

DOC-BR (FUG BR)

+ Noticias

Sem conta? Crie uma

Links

Ns estamos regularmente na Internet. Quando achamos um site legal ns o listamos aqui para o seu divertimento. Da lista abaixo selecione uma categoria e ento um site para visitar.


Tutoriais/Howtos (7) FreeBSD ISOs (12) FreeBSD Misc (15) NetBSD (1) OpenBSD (5) Downloads Recomendados (5) Sites de Usurios (4) Geral (12)

[Voltar]

FUG-BR - Espalhando BSD

Dicas Rpidas:

O portsclean(1) é uma ferramenta que limpa todo o diretório work/ do ports(7). Além de liberar espaço em disco ele é capaz de remover arquivos antigos que não possuem referência no /usr/ports/distfiles.

#portsclean -C
Limpa o diretorio work/

#portsclean -D
Limpa o diretorio distfiles/

#portsclean -i
Modo interativo, pergunta se você quer remover o arquivo

Recomendado
#portsclean -CDi

Wallpapers

Fontes Externas

Yesterday I posted Latest PhD Thesis Title and Abstract. One of my colleagues Ben Buchanan subsequently contacted me via Twitter and we exchanged a few messages. He prompted me to think about the title.

Later I ruminated on the title of a recent book by my advisor, Dr. Thomas Rid. He wrote Cyber War Will Not Take Place. One of the best parts of the book is the title. In six words you get his argument as succinctly as possible. (It could be five words if you pushed "cyber" and "war" together, but the thought alone makes me cringe, in the age of cyber-everything.)

I wondered if I could transform my latest attempt at a thesis title into something that captured my argument in a succinct form.

I thought about the obsession of the majority of the information security community on the tool and tactics level of war. Too many technicians think about security as a single-exchange contest between an attacker and a defender, like a duel.

That reminded me of a problem I have with Carl von Clausewitz's definition of war.

We shall not enter into any of the abstruse definitions of war used by publicists. We shall keep to the element of the thing itself, to a duel. War is nothing but a duel on an extensive scale.

- On War, Chapter 1

Clausewitz continues by mentioning "the countless number of duels which make up a war," and then makes his famous statement that "War therefore is an act of violence to compel our opponent to fulfill our will." However, I've never liked the tactically-minded idea that war is a "duel."

This concept, plus the goal to deliver a compact argument, inspired me to revise my thesis title and subtitle to the following:

Campaigns, Not Duels: The Operational Art of Cyber Intrusions

In the first three words I deliver my argument, and in the subtitle I provide context by including my key perspective ("operational art"), environment ("cyber," yes, a little part of me is dying, but it's a keyword), and "intrusions."

When I publish the thesis as a book in 2018, I hope to use the same words in the book title.

Latest PhD Thesis Title and Abstract

In January I posted Why a War Studies PhD? I recently decided to revise my title and abstract to include attention to both offensive and defensive aspects of intrusion campaigns.

I thought some readers might be interested in reading about my current plans for the thesis, which I plan to finish and defend in early 2018.

The following offers the title and abstract for the thesis.

~~Network Intrusion Campaigns: Operational Art in Cyberspace~~

Campaigns, Not Duels: The Operational Art of Cyber Intrusions*

Intruders appear to have the upper hand in cyberspace, eroding users' trust in networked organizations and the data that is their lifeblood. Three assumptions prevail in the literature and mainstream discussion of digital intrusions. Distilled, these assumptions are that attacks occur at blinding speed with immediate consequences, that victims are essentially negligent, and that offensive initiative dominates defensive reaction.

This thesis examines these assumptions through two research questions. First, what characterizes network intrusions at different levels of war? Second, what role does operational art play in network intrusion campaigns?

By analyzing incident reports and public cases, the thesis refutes the assumptions and leverages the results to improve strategy.

The thesis reveals that strategically significant attacks are generally not "speed-of-light" events, offering little chance for recovery. Digital defenders are hampered by a range of constraints that reduce their effectiveness while simultaneously confronting intruders who lack such restrictions. Offense does not necessarily overpower defense, constraints notwithstanding, so long as the defenders conduct proper counter-intrusion campaigns.

The thesis structure offers an introduction to the subject, and an understanding of cybersecurity challenges and trade-offs. It reviews the nature of digital intrusions and the levels of war, analyzing the interactions at the levels of tools/tactics/technical details, operations and campaigns, and strategy and policy. The thesis continues by introducing historical operational art, applying lessons from operational art to network intrusions, and applying lessons from network intrusions to operational art. The thesis concludes by analyzing the limitations of operational art in evolving digital environments.

*See the post Updated PhD Thesis Title for details on the new title.

Lt Gen David Deptula on Desert Storm and Islamic State

This weekend Vago Muradian interviewed Lt Gen (ret) David Deptula, most famous for his involvement as a key planner for the Desert Storm air campaign.

I recommend watching the entire video, which is less than 8 minutes long. Three aspects caught my attention. I will share them here.

First, Lt Gen Deptula said that Desert Storm introduced five changes to the character of warfare. I noted that he used the term "character," and not "nature." If you are a student of warfare and/or strategy, you are most likely in the camp that says warfare has an unchanging nature, although its character can change. This is the Clausewitz legacy. A minority camp argues that warfare can change both nature and character.

Second, turning to the five changes introduced by Desert Storm, Lt Gen Deptula listed the following.

1. Desert Storm introduced "expectations of low casualties, for both sides." I agree with the expectation of low casualties for the US, but I don't think low Iraqi casualties were a primary concern. One could argue that stopping the war during the "highway of death" showed the US didn't want to inflict large casualties on the Iraqi forces, but I still think low casualties were primarily a concern for US troops.

2. Desert Storm "normalized precision." Even though a minority of the ordnance delivered during the war were precision weapons, their use steadily increased throughout all later conflicts.

3. Desert Storm introduced joint and combined organization and execution. This was indeed quite a step forward, although I recall reading that that USMC airpower took measures to remain as separate as possible.

4. Desert Storm put the concepts of "effect-based operations" into action. There is no doubt about this one. Lt Gen Deptula talks about a disagreement with Gen Schwartzkopf's staff concerning disabling the Iraqi power grid. Air power achieved the effect of disabling the grid within 3-4 days, but Schwartzkopf's team used traditional attritional models, noting that less than a certain percentage of destruction mean mission failure. Deptula was right; they were wrong.

5. Desert Storm was the first major conflict where airpower was the centerpiece and key force. Call me biased, and no disrespect to the land forces in the Gulf, but I agree with this one.

The third and final noteworthy element of the interview involved Lt Gen Deptula's opinion of Islamic State. He said "it's not an insurgency. IS is a state." He said IS possesses the five elements of a state, namely:

1. Leadership
2. Key essential systems
3. Infrastructure
4. Population
5. Fielded military forces

I agree with his assessment. I also believe that Western leaders are unwilling to grant IS the legitimacy of it being a state, so they persist in calling IS names like ISIS, ISIL, Daesh, and so on. I see no problem with that approach, since it incorporates political sensitivities. However, that approach also aggravates the perception that Western leaders are out of touch with reality.

Why a War Studies PhD?

When I begin receiving multiple questions on a topic, it's a signal that I should write a blog post.

Several of you have asked me about my experience as a PhD candidate in the King's College London Department of War Studies. In this post I will try to answer your questions by explaining how I got to this point and my overall impressions about the program.

My Academic Background

I have bachelor's of science degrees in history and political science from the US Air Force Academy, and a master's degree in public policy from the Harvard Kennedy School. My last formal academic training ended in 1997 when I graduated from the Air Force Intelligence Officers Training Course.

Why a PhD?

I seriously began considering working on my PhD in 2006, when I was an independent consultant. I've guest lectured at dozens of schools over the years, and taught hundreds of students through my Black Hat courses. I thought the PhD experience would open more doors for future academic opportunities, and I welcomed the opportunity to make an original contribution to the literature. In more recent years I've testified to Congress and worked with think tanks, and in both environments PhDs are common.

My First PhD Choice

After reading Security Engineering (the first edition), I was a fan of Dr Ross Anderson at the University of Cambridge Computer Laboratory. I contacted him, as well as some of his PhD candidates. They invited me to guest lecture at the lab, which I did in May 2006. I considered the possibility of doing research on network security motioning. I liked the idea of the "British system," which emphasized practical research, no coursework, and a high degree of independence. I would have to move my family to the UK.

In the spring of 2007, however, I made contact with my future boss at General Electric. I decided instead to join GE as director of incident response. It was too good an opportunity. That put my PhD plans on hold.

A New Direction

In the fall of 2012 I listened to a 24 lecture series titled Masters of War: History's Greatest Strategic Thinkers by Professor Andrew R. Wilson of the Naval War College. Dr. Wilson reintroduced me to the strategists I had learned about as a cadet twenty years earlier, and kindled a deep interest in strategic history, thought, and practice. I began looking for military history and strategy programs, starting with this list maintained by the Society for Military History.

In the summer of 2013, The Economist magazine asked if I would participate in an online debate with Dr Thomas Rid, author of Cyber War Will Not Take Place. After the debate I read Thomas' book, and learned he was a professor in the KCL War Studies department. I enjoyed the debating process and Thomas' book, so I decided to contact him and some of his PhD candidates to learn more about the PhD program.

During that process, FireEye acquired Mandiant in late December 2013. I decided to change roles and become a full-time strategist, inspired by my changing interests and Prof Wilson's course. That decision definitively shifted my focus away from tools and tactics, and towards operations/campaigns and strategy.

My Final PhD Choice

In early 2014 I connected with Rob Lee, who had started his PhD with Thomas in the fall of 2013. Speaking with Thomas and Rob, I learned the KCL War Studies PhD was even more to my liking than the Cambridge program. KCL also emphasized practical research, no coursework, and a high degree of independence. I would not have to move my family to the UK, but I would have to be very disciplined and stay in contact with my advisor and colleagues.

I applied to the program to meet the spring 2014 deadline, with enrollment in fall 2014. I was accepted and started the program in the fall of 2014, while still maintaining my day job at Mandiant and FireEye.

The Thesis

The desired output for the KCL PhD is a thesis, a 80,000 to 100,000 word work with a goal of eventual publication as a book. Since I was already considering writing my fifth book, this seemed an excellent way to accomplish that goal. Others might find this a scary proposition, but I always enjoyed self-paced research, and the opportunity to devise and answer original research questions was appealing.

Milestones

I will shift my focus slightly to those who might be interested in applying to the program. The PhD program offers three major milestones. First, one must be accepted to the program. I recommend perusing the list of people to find faculty and current students with interests similar to yours. Contact them via email to identify possible advisors and colleagues. If you aren't able to attract any interest, it's a sign you might not have a topic suitable for a PhD. That's a personal judgement, of course.

I approached the application process very seriously. I took several months to complete it and submitted my Strategy, Not Speed piece as my writing sample. Thankfully I was accepted!

Once in the program, the second major milestone is called the "mini viva" or the "upgrade." Prior to passing this milestone, as I understand it, one is not technically a PhD candidate yet. One must write a document of about 20,000 words that includes a thesis abstract, outline, introductory chapter, sample chapter, and completion work plan. The student must then defend that document, live, in front of a panel. I passed that stage of my PhD journey late last year.

The third and final major milestone is the "viva" or the defense of the completed thesis. I am several years away from this step, but I expect it to be an extended version of the upgrade process. Remember that one of the purposes of a PhD is to demonstrate the ability to produce high-level, independent research, so I expect my viva to reflect that philosophy.

My Experience

My experience thus far has been excellent and I plan to continue. However, I would like to highlight a few aspects of my situation. First, I am doing research independently, not at the Strand campus in central London. Several of my colleagues are there now, and they have daily access to a whole world of academic experiences that are unavailable to remote students. If you want a campus experience, you should study in London.

Second, I am still working my day job and being a husband and father, which are my priorities. That means I have to be very careful about how I manage my time. I felt that I could handle the situation, based on my experience writing and publishing my last book. I started writing my last NSM book in January 2013 and had it ready for Black Hat in late July that year, during the time when Mandiant released the APT1 report.

Third, my thesis, the nature of counter-intrusion campaigns, dovetails well with my day job and professional interests. I would not be able to pursue a PhD in a field not related to my professional life -- I simply wouldn't have the time for research. Because my research matches the needs and interests of my employer, the work I do for Mandiant and FireEye frequently doubles as research for my PhD. Obviously I have a very flexible employer who supports my research, and for that I am grateful.

Fourth, although I am independent, thanks to the initiative of colleagues in the DC area, I am not alone. Last month one of us started a group for War Studies students in the DC area, and we plan to have monthly meetings. I also try to meet with KCL personnel (students or faculty) if we happen to be in the same part of the world at the same time. I started a Slack channel but it hasn't really yet taken off.

Recommended Reading

In addition to reading the KCL and War Studies Web sites, I suggest reading Authoring a PhD by Patrick Dunleavy. It is generally aimed at the British PhD process, focusing on the so-called "big book" thesis. If you find the sort of research and writing described in that book to be exciting, then a KCL PhD might be for you.

Conclusion

In brief, I recommend the KCL War Studies PhD if you meet the following requirements:

You have a suitable undergraduate background, temperament, and social and financial situation, such that you are capable of independent research at the highest level.
You have an interest that syncs with at least one possible advisor in the department.
You are committed to researching for several years, and writing 80,000-100,000 words on your subject, answering research questions to make original academic and practical contributions to the field.

I may add updates to this post, or simply add them as comments or as answers to questions.

Happy 13th Birthday TaoSecurity Blog

Today, 8 January 2016, is the 13th birthday of TaoSecurity Blog! This is also my 3,000th blog post.

I wrote my first post on 8 January 2003 while working as an incident response consultant for Foundstone. Kevin Mandia was my boss. Today I am starting my third year as Chief Security Strategist at FireEye, still working for Kevin Mandia. (It's a small world. In April I will hit my five year anniversary with the Mandiant part of FireEye.)

In 2015 my blogging frequency increased dramatically, with 55 posts, more than double my 2014 total of 23 and triple my 2013 output of 18. In 2012 I posted 60 stories, so I was close to that level in 2015. It's still nothing like my writing from 2003-2011 however!

Why the drop over the years? I "blame" my @taosecurity Twitter account. With almost 36,000 followers, easy posting from mobile devices, and greater interactivity, Twitter is an addictive platform. I have authored roughly 16,000 Tweets since first posting in July 2009.

Second, blogging used to be the primary way I could share my ideas with the community. These days, speaking and writing are a big part of my professional duties. I try to track media reports here and I archive my non-blog writing at my Academia.edu account.

Third, time is precious, and blogging often takes a back seat. I'd rather spend time with my family, write and research my PhD, collaborate with think tanks, and so on.

I still plan to keep blogging in 2016. Twitter's only a 140 character platform, and some days I have the time and inclination to share a few thoughts beyond what I've said or written for work. I have to decide if I want to write about strategy here, or move to another location.

Thanks you to Google for providing me this free platform for the past 13 years, and to you for reading what I post. I'm one of the few original "security bloggers" still active, though not writing in the same way as I did in 2003.

I realize my transition from technical details to strategic considerations has alienated some readers, but I am comfortable with my interests and I believe the greater security community needs to hear from people who think outside the tools and tactics box. This is especially true when the majority of the security community isn't aware they are inside such a box, or that there is another set of ideas and people available to contribute to the world's digital safety and security.

2014-2015 Professional Reading Round-Up

A Brief History of the Internet in Northern Virginia

Domain Creep? Maybe Not.

Not So Fast! Boyd OODA Looping Is More Than Speed

Seven Tips for Personal Online Security

Daemonic Dispatches Musings from Colin Percival
Write opinionated workarounds

A few years ago, I decided that I should aim for my code to be as portable as possible. This generally meant targeting POSIX; in some cases I required slightly more, e.g., "POSIX with OpenSSL installed and cryptographic entropy available from /dev/urandom". This dedication made me rather unusual among software developers; grepping the source code for the software I have installed on my laptop, I cannot find any other examples of code with strictly POSIX compliant Makefiles, for example. (I did find one other Makefile which claimed to be POSIX-compatible; but in actual fact it used a GNU extension.) As far as I was concerned, strict POSIX compliance meant never having to say you're sorry for portability problems; if someone ran into problems with my standard-compliant code, well, they could fix their broken operating system.

And some people did. Unfortunately, despite the promise of open source, many users were unable to make such fixes themselves, and for a rather large number of operating systems the principle of standards compliance seems to be more aspirational than actual. Given the limits which would otherwise be imposed on the user base of my software, I eventually decided that it was necessary to add workarounds for some of the more common bugs. That said, I decided upon two policies:

Workarounds should be disabled by default, and only enabled upon detecting an afflicted system.
Users should be warned that a workaround is being applied.

FreeBSD on EdgeRouter Lite - no serial port required

I recently bought an EdgeRouter Lite to use as a network gateway; I had been using a cheap consumer wifi/NAT device, but I wanted the extra control I could get by running FreeBSD rather than whatever mangled version of Linux the device came with. Someone wrote instructions on installing FreeBSD onto the EdgeRouter Lite two years ago, but they rely on using the serial port to reconfigure the boot loader — perfectly straightforward if you have a serial cable and know what you're doing, but I decided to take the opportunity to provide a more streamlined process.

A challenge to startups

"From those unto whom much has been given, much shall be expected." In various forms this sentiment has been expressed at least as far back as the third century AD, via the Gospel of Luke; more recently it has been cited frequently by US Presidents, and can be seen in modified form in such places as Spider-Man ("With great power comes great responsibility") and the demands of the Occupy movement that the "1%" pay higher taxes. I started thinking about this a few days ago after re-reading an essay by Paul Graham and thinking about how lucky I was to be running a startup company now rather than two decades ago.

The design of my magic getopt

When I started writing the blog post announcing my magic getopt, I was intending to write about some of the design decisions which went into it. I changed my mind partway through writing: My readers probably cared about the functionality, but not about the ugly implementation details. It turns out that my original plan was the right one, as I've received questions about nearly every design decision I made. Since this clearly is of interest to my readers, here's the reasons behind some of the decisions I made while writing that code.

A magic getopt

Parsing command lines in C is easy when all of the options are single characters: You pass your command line to getopt along with a string containing all the valid options; then you have a switch statement with a case for each option you want to handle. It looks something like this:

        int ch;
        while ((ch = getopt(argc, argv, ":af:")) != -1) {
                switch (ch) {
                case 'a':
                        aflag = 1;
                        break;
                case 'f':
                        printf("foo: %s\n", optarg);
                        break;
                case ':':
                        printf("missing argument to -%c\n", optopt);
                        /* FALLTHROUGH */
                default:
                        usage();
                }
        }

Unfortunately if you want to add support for long options — say, to accept a new --bar option — you need to switch to using getopt_long and your list of options is no longer confined to the options-processing loop:

enum options
{
	OPTION_BAR
};

...

static struct option longopts[] =
{
	{ "bar", required_argument, NULL, OPTION_BAR }
};

...

        int ch;
        while ((ch = getopt_long(argc, argv, ":af:", longopts, NULL)) != -1) {
                switch (ch) {
                case 'a':
                        aflag = 1;
                        break;
		case OPTION_BAR:
			printf("bar: %s\n", optarg);
			break;
                case 'f':
                        printf("foo: %s\n", optarg);
                        break;
                case ':':
                        printf("missing argument to -%c\n", optopt);
                        /* FALLTHROUGH */
                default:
                        usage();
                }
        }

Rather than adding a new option in one place (or two, if you count the list of options at the top of the loop as being a separate place), new long options require changes in three places — one of which (the enum) is often placed in an entirely separate file. So much for keeping code clean and free of duplication. There has got to be a better way, right?

Enter magic getopt. Via a little bit of macro magic, the above options-handling code turns into this:

        const char * ch;
        while ((ch = GETOPT(argc, argv)) != NULL) {
                GETOPT_SWITCH(ch) {
                GETOPT_OPT("-a"):
                        aflag = 1;
                        break;
                GETOPT_OPTARG("--bar"):
                        printf("bar: %s\n", optarg);
                        break;
                GETOPT_OPTARG("-f"):
                        printf("foo: %s\n", optarg);
                        break;
                GETOPT_MISSING_ARG:
                        printf("missing argument to %s\n", ch);
                        /* FALLTHROUGH */
                GETOPT_DEFAULT:
                        usage();
                }
        }

with each option listed just once, at the point where it is handled.

The HTTP 500 Solution

My online backup service offers bug bounties for mistakes in the client software; while I explicitly exclude bugs in the Tarsnap website (with the exception of cosmetic errors) in an attempt to discourage people who blindly run vulnerability scanners against websites, I still get a lot of bogus "bug reports". One of the more common reports is "I managed to trigger an HTTP 500 Internal Server Error" response; what people don't realize is that this is in fact entirely deliberate, as part of what I call the "HTTP 500 Solution".

A FreeBSD AMI Builder AMI

I've been working on the FreeBSD/EC2 platform for a long time; five years ago I finally had it running, and for the past few years it has provided the behaviour FreeBSD users expect — stability and high performance — across all EC2 instance types. Making the platform work was just the first step though; next comes making it usable.

Some people are happy with simply having a virtual machine which runs the base FreeBSD system; for them, the published FreeBSD/EC2 images (which, as of FreeBSD 10.2-RELEASE, are built by the FreeBSD Release Engineer) will be sufficient. For users who want to use "stock" FreeBSD but would like to have some extra setup performed when the instance launches — say, to install some packages, edit some configuration files, and enable some services — I wrote the configinit tool. And for users who need to make changes to FreeBSD itself, I added code for building AMIs into the FreeBSD source tree, so you can take a modified FreeBSD tree and run make ec2ami to generate a reusable image.

There was one group for whom I didn't have a good solution yet, however: Users who want to create FreeBSD AMIs with minor changes, without wanting to go to the effort of performing a complete FreeBSD release build. Ironically, I am exactly such a user: All of the EC2 instances I use for my online backup service make use of spiped to protect sshd and provide encrypted and authenticated tunnels to my mailserver and package server; and so having spiped preinstalled with the appropriate keys would significantly streamline my deployment process. While it's possible to launch a FreeBSD EC2 instance, make some changes, and then ask EC2 to create a new AMI out of it, this rarely produces a "clean" AMI: A lot of code runs when an EC2 instance first launches — creating the ec2-user user, installing the appropriate SSH public key, creating SSH host keys, growing the root filesystem if launched with a larger root disk, downloading and installing updates to FreeBSD, downloading and installing packages... — and much of this needs to be manually reverted before a reusable AMI can be created; not to mention command histories and log files written during the configuration process, which the more fastidious among us may wish to avoid publishing. To solve this problem, I present the FreeBSD AMI Builder, now available as ami-28682f42 in the EC2 US-East-1 region.

Tarsnap email confirmation bypass

Over the past four years, Tarsnap's bug bounties have received quite a bit of attention. Most of it has been very useful — almost 400 mistakes (most either cosmetic or harmless, but some of them significant) have been reported and fixed — but it does also get some unwanted attention: Despite my clear statement that Tarsnap's bug bounties are for problems in tarsnap code, not for problems in the website, I regularly see people running automated vulnerability scanners... which invariably yield a selection of absurd non-vulnerability "vulnerabilities".

One consequence of these unsolicited security scans is that — since they feed a variety of inputs to forms, including the account creation form — I see a lot of obviously fake signup attempts (alas, none yet from the world's most obviously fake domain name). These are harmless, since the signup code sends out a confirmation email and the account isn't actually created until the alleged registrant follows a link in that email; so I wasn't concerned when I received an email last week telling me that someone was trying to create an account as admin@tarsnap.com.

Five minutes later, I was very concerned upon receiving an email telling me that the registration for admin@tarsnap.com had been confirmed and the account created.

Safe from what?

I woke up this morning to a headline news story on CBC's website: Is your baby monitor safe? According to a literal reading of Betteridge's law of headlines, the answer to this question should be "no", although if you consider the spirit of the law — as a commentary on sensationalist journalism — then the answer should probably be "yes". To me, neither answer makes sense, because the question itself doesn't make sense.

Tarsnap $1000 exploit bounty

For somewhat over four years, Tarsnap has been offering bounties for bugs found in the Tarsnap code. Two thirds of the bounties Tarsnap has paid out have been $1 each for cosmetic bugs (e.g., typos in source code comments), and a quarter of the bugs have been $10 each for harmless bugs — mostly memory leaks in error paths where the tarsnap client is about to exit anyway — but there have also been some more serious bugs: Several build-breakage bugs ($20 each); a variety of cases where tarsnap behaviour is wrong in a user-visible — but generally very obscure — way ($50 each); a few crashes ($100); and of course the critical crypto bug which first convinced me to offer bounties.

Most bugs are straightforward, but occasionally one comes up which is not so clear in its impact. Such is the case with a bug which is fixed in tarsnap 1.0.36. This bug causes the NUL string termination byte to overflow the heap-allocated buffer used for paths of objects examined as tarsnap traverses a directory tree; such one-byte heap overflows have been shown to be exploitable in the past. In the case of tarsnap, I will be very surprised if it turns out to be possible to cause anything worse than a crash, but I can't absolutely rule out the possibility.

In light of this, Tarsnap is offering a $1000 exploit bounty: The first person before the end of 2015 who can convincingly demonstrate a serious exploitation of this bug will receive $1000. While there are many organizations which pay more than this for exploits, I think this is a reasonable prize: After all, I'm already telling you what the bug is which you need to exploit! Fine print: No bounty if you're in Iran, North Korea, or some other problem countries. Bounties are awarded at my sole discretion; in particular, I get to decide whether the "convincingly demonstrate" and "serious exploitation" conditions are satisfied. Payment by US dollar check or paypal. To avoid races, contact me before publishing anything. If you can't accept cash prizes, the bounty can be donated to a mutually-acceptable charity of your choice.