The trouble with Open Source...

is that it just doesn't earn the big bucks!



I just finished reading an article from a British Computer Society member called

The trouble with open source

Now I'm both the first person to evangelize open source but also the first to point out that it, like everything else, is imperfect. This article happened to identify several issues, however, some of which I take issue.



The author, a certifiable fellow identified as "Stephen J Marshall CEng MBCS CITP" grants OSS some validity, if only as having academic value. He refers to it as a "widely talked about" and "influential" "phenominon" with a utopian vision of free software. He refers to the champions of this vision as "high-profile pressure groups", citing the Free Software Foundation and Electronic Frontier Foundation as two.

As the catalyst for widespread OSS adoption, he explains quite correctly about the fears associated with vendor lock-in: all-eggs/one-basket, dimishing (or lets face it, "NO") support from vendors, never-ending cycle of upgrades whence there is no return.


He continues to decry some of the most powerful business benefits of OSS: large developer-base, likelihood of longevity, the option to bring critical development in-house, should the project-owners disappear, etc...



The author then changes the tone of his article with the phrase "become captivated by the idea of a free-lunch," then launching into his opinions of OSS weaknesses. Below, I'll list his issues, a summary of his meaning, and my own perspective (which is, of course, why you read my blog, right? ;)



* Intellectual Property: code written by employees is owned by the company, regardless of when they write it. Only losers with zero experience are allowed to write OSS.



= I'll have to verify the laws in the US, but the UK sounds rather draconian in this regard. I quess it's a good thing we told 'em where to stick it when we did. Beyond the differing legal-systems between countries, many companies officially contribute their own IP to OSS, as well as providing employee work-hours to benefit OSS. Look at many of the software projects which have made it to the bigtime. Most of them have corporate backing and/or corporate ownership. Beyond even that, part of the draw of OSS is the ability of a developer or team to prove their value in an open forum where their software might get noticed. Some OSS code is resume-ware

= Still, the author's comments aren't without lessons:

== Investigate the code you use before you rely too heavily on it. Get to know the developer=base and background a little and get a feeling for its overall quality. This is know different from the proprietary world, except the proprietary vendors are much more skilled at deception.



* Conceptual Integrity: OSS projects don't have leadership with any vision or control. Quality control is done on the first adopters



= Hogwash. First of all, generalizing about OSS is like characterizing every person on the planet. That said, OSS projects are almost as likely to have leadership with vision and control as proprietary code. Either way, it's a gamble. The key difference is driving-force. OSS is not driven by a marketting sheet and budget as their proprietary cousins. OSS is driven primarily by features and quality, neither of which are guaranteed. Furthermore, OSS projects are often a labor of love, being conceptualized and owned by the project leader(ship). This relationship is very powerful, more powerful than a paycheck often ensures. As for quality control, I can't say there isn't a bit of truth there. I have fallen victim to the occasional bug finding me. I refuse to condone it, as the quality of software needs to improve. I will point out that I have been bitten equally by proprietary vendor bugs. The difference is that the OSS bugs are free. Yes, you may be able to get the bugs fixed quickly by pay-for products faster than free ones... but I haven't met a OSS developer which wouldn't fix your problem quickly for a marginal fee. Difference: much faster, much cheaper, pay-as-you-go.

= Still, there are lessons to be gained here as well. QC/QA *really* need to improve, industry-wide. The software industry was at an all-time-low just a few short years ago. It appears to be improving slowly. This *must* be a continued effort, learning from the experience we've gained. Heck, most of the *reason* OSS has gained popularity is the lack of software quality in the proprietary world.



* Professionalism: duh.



= Ok, I can't knock this one very hard. I've seen the bedside manner of certain OSS developers. I know that as a geek I have to work hard for professionalism... I will say that paid developers tend to be more willing to make the effort... particularly in the OSS space. Stop thinking that OSS means immonetary! That short-sighted viewpoint will continue to cause difficulties in the software world. Support for corporate use is practically a given, a requirement many corporations will demand. This is where SuSE/Novell has a great deal of appeal.

== What to learn? 1) Be nice, guys! 2) Consider the needs of those to whom you are communicating.



* Innovation: wimpy little wannabe developers can't think up anything fun and new.



= Wow! I'm pissed off *for* the developers! They should be quite insulted. Is this guy a lunie or simply on the corporate payroll? He has obviously never used Mozilla, Linux (for so *many* innovations), Thunderbird, Apache, GAIM, Konqueror, KDE, Gnome, Unison, rsync, APT, and so many others which have put their proprietary cousins to innovative shame on countless occasions.



= Lessons? There are many who have opinions. Use those opinions to limit *test-driving* solutions, not negating them.



The paper goes on to mention some drivel, particularly focusing on the detriment of software vendors who cannot compete. I can understand how this space can be difficult. Problem: many corporate software vendors get outrageous amounts of money for limited value, buggy software I could write in a couple months. Why shouldn't OSS projects put the pressure on these? The software industry is certainly being shaken up with the acceptance (and relative maturing) of OSS. The reasonably-priced, higher-value software should have less to worry about from the OSS world. If they are offering significant value, OSS developers are less likely to target the space (ok, this isn't a scientific view, I suppose they might get an itch). $100k for a piece of software which could be written by a team of 3 in a month... Something is specifically wrong with that. It's why I rejoined the development community ;)

However, there are new areas of development which OSS has opened up, building upon OSS. ISVs are starting to harness the Linux platform to lower the costs of development, deployment, and improve visibility into the OS. Smart ISVs are learning to harness the power of OSS, even when they do not offer their own. The author is correct in stating the importance of the "middle-class" developer. I offer my respect and support to those, and hope for them intelligent business decisionmaking. Software companies have so much to offer, even in the OSS world we seem to be increasingly embracing.



To finish off the article, we find the author's fear of UK governmental preference tending toward OSS in detriment to software vendors, listing cost as the primary decisionmaker for the UK government. (wait a minute, I thought OSS was illegal!) I believe this is the cause for this article. Some valuable insights were shared, but overall it did indeed seem to be very closed-minded and old-school, neither of which work very well in the new technology age. No disrespect to the author, the article was well-articulated. The opinions are his, and his right to express them is what makes the web and open governments so great.



Before writing him off, however, let's be sure to keep in mind the lessons and concerns listed above. Learn from all you can, whether the opinion be pro or con.

Suck butt!

Man, this has not been my week! Last Friday I received a deadline for a project I was not really ready for (deadline: change by Thursday with international communication and preparation, usually requiring nearly a week of lead-time).


Friday was also a meeting with my local IT Security professional group. I should not have gone, given my deadline. But like the moron I continually prove myself to be, I went... but wait, the moron story continues.

Thinking the location had wireless Internet for visitors, I fired up Kismet to figure out what settings I needed for Internet access to VPN back and keep abreast of the developments in my project. I would have asked but I was already 15 minutes late and didn't want to disrupt the meeting further. There was one unencrypted network, but the SSID wasn't broadcast. Hoping for something identifiable as "visitor" or "public" or something else, I thought I'd let it sit for a minute and pick up the SSID. I got distracted by the meeting (and a little bit of tinkering to get echod to return correctly), I forgot about Kismet running until the location security officer came and squatted next to me.

The gentleman asked me what I was doing on wireless. I was about to say "nothing" when I remembered Kismet was running. Kismet is undetectable, but honesty is important to me, so I showed him the Kismet window. I honestly didn't expect him to get angry, but he did. Visibly disturbed, he asked me to delete the datafiles collected by Kismet. I obviously didn't have any problem with that, so not only did I remove the data files, but passed them through the shredder first (unix command "shred") to make sure they were unrecoverable.

The gentleman still didn't seem very pleased, so I suggested that we take a walk. I apologized profusely, he told me quite firmly that this was unacceptable. He then asked me to never again bring a computer or other device/tool to their location. While I thought that was a bit harsh, I agreed.



Let me take a moment for an aside. Kismet is a wireless audit tool which is completely passive, leaving no indication of its use. It does not cause damage or disruption of service. Due to its invisible nature, I expect that everyone is running Kismet on my network at some point or another. Educated defense must expect this, in my opinion. Still, I need to capitalize on this opportunity to learn...



Back on track. I get a voice-mail from my boss at 6:45pm. Although I was feeding my infant and packing for a trip, I knew I'd better call him back (I'd have talked to him sooner but he forgot to turn on his cell-phone ringer).

The gentleman had contacted my boss, and was very angry (partly because *he too* had to wait for my boss's cell-phone issue), and demanded that my laptop be siezed and wiped. (let's be reasonable, this is *my* laptop!)

My boss kindly asked what was planned for the laptop over the weekend. He asked if I could bring it in just to have my counterpart forensic analyst verify that I did what I said to the other gentleman. Wanting to be helpful (I have nothing to hide) I told him I would leave it home and not touch it. Of course, I started having hard drive issues the day before. @#$%!



I'm running out of time, and you're likely out of interest. To make a long story short, my hard drive was failing, but we were able to get a good image (like the third or fourth try), of course I hadn't done anything nepharious, and I had nothing to hide. They were able to clear my name (as much as was possible), mid-week... It was a difficult week, busy and hectic and draining.

Thank God it's over. It's still hectic and crazy, but at least I learned a few things:

1. There are many people driven by fear (or worse), not knowledge


2. I must learn to keep out of danger from those people


3. Honesty has a slow ROI, but a very powerful one

My boss and team lead were both very supportive, because they know and have come to trust me and my intentions. They know I value and effort integrity. Their support was very well appreciated.

bon voyage, Atlas!

Not only is atlas going on vacation, but he's not coming back! (well, at least not to this blog)

atlas has his new own blogspace set up here:

http://atlas.r4780y.com/

Enjoy and farewell, my friend.

Stick a fork in echod - atlas again

echod is now on life support only. Officially dead, I now wish to clean up my sploit to have it continue execution. We'll have to see about that one. :\ Can't say I've ever written a sploit to return, but this seems like a great time to start.

It's actually been a week since I've been able to touch it, so I'm not feeling quite as lame as I was last week. Work has extended into the evenings and then there was the wedding I had to liven up :) (kudos to Ryan and Rachel!)

This round in my fight with echod was much less confounding. I had already structured the exploit code so I could tinker with the header (as the term suggests, I'm speaking of the initial set of bytes which hold the address to overwrite the return pointer and some other goodies used to reconstruct the stack... remember that everything is reversed). The string dynamically generates NOPs to correct the buffer size from any changes.

Since that was already in place, I simply pumped some net-bind shellcode through "reverse()" and appended the resulting string to the sploit header (thanks again, Metasploit!). This broke stuff at first. It seems some of the memory the shellcode was occupying gets altered before execution. Solution? Add some NOPs after the header, before the shellcode, and check again. I ended up using 96 (nice round number) NOPs for this as 32 and 56 were not enough. Surprisingly, that provided a stable/consistent exploit.

As an exercize, I then wrote three while loops:

*) one to check the service and restart it if dead

*) one to run the exploit, connect using netcat, read, then overwrite a simulated "key" file, like in the CTF

*) one to check the "key" file and overwrite it with the correct value if overwritten

These have been going now for some time and working quite nicely. Now, I just need to turn my attention to returning gracefully. I believe the appropriate course of action is to "mov 0x 0x4(%ebp)" and then call "ret" instead of calling "exit()". We'll see how that works out.

I'll let you know. I feel awful right now and am driving home from Skelletones, so coding has stopped. Between the fog and deer-hazards, blogging is all I can manage! Perhaps if I felt better ;)

@