2010 06 13

From TheCommandLineWiki

Jump to: navigation, search

Contents

News Cast for 2010-06-13

(00:17) Intro

(02:48) Security alerts

(03:07) Diffusing botnet control systems increases their robustness

  • http://threatpost.com/en_us/blogs/botnets-using-ubiquity-security-060710
  • Kaspersky Labs unpacks an interesting technical trend in botnets
  • In the last few years, they've shifted from a few, centralized command & control servers
    • To a peer-to-peer model where command and control is distributed throughout
    • And any node can help out in the face of defenders compromising the network
  • Use more c&c nodes makes them easier to spot, take down
    • But it means there are more of them to take down
  • The article looks specifically at the Grumblar botnet
  • They've taken down hundreds of infected systems in the past few months
  • It has had little to no effect on the network
  • As far as they can tell, there are still thousands of nodes in the network
  • It makes sense as legitimate software uses the same techniques
    • For very similar reasons, specifically resistance to failure
  • Distributed data stores like Cassandra can lose a node and keep running
  • Admins can add nodes in to recover from failure or increase horsepower
  • Since intelligence is distributed, the cost of growing a cluster or a p2p botnet
    • Is much lower than more traditional, centralized systems
  • To wipe out a bot net like Grumblar, every node would potentially need to be eradicated
  • The nodes are hardly standing still while they are being compromised
  • New versions of the botnet's software and the malware that spreads it
    • Are constantly being released with improvements like obfuscation, encryption and code morphing
  • You could compare this type of botnet to a biological system
  • There are fewer linear dependencies increasing the costs of impacting it
  • It also only requires a small breeder population for the botnet to restore itself
  • We are probably going to need something new on the large scale
    • Like biologists looking how to interfere with bacteria's communication chemistry
  • In the meantime, distributed users and admins need to keep doing their best
    • To patch and secure systems to give them less systems on which to fuel their growth

(05:29) Bad passwords and the economics around perpetuating them

  • http://arstechnica.com/security/news/2010/06/content-providers-phishing-for-demographic-data-via-logins.ars
  • John Timmer at Ars Technica reminds us of the problems with passwords
  • They are dependent on our ability to effectively remember and manage them
  • It is hardly surprising we end up doing such a poor job of using secure ones
  • In this context, he explains some research mixing economics and security analysis
  • A new paper from a pair of researchers out of Cambridge
    • Looked at the password security practices at a few of the top sites
  • They wanted to quantify how many of the sites support best practices
    • The only ways we can make passwords, as flawed as they are, at least somewhat effective
    • Such as not using dictionary words, including special symbols, longer passwords
  • Their results are very discouraging, concluding most popular sites
    • Only engage in security theater around password policies
    • The articles details the depressing breakdown of how few do anything
      • That enhances user security in any meaningful way
  • On the economic side, they looked at the motives behind this state of affairs
  • The worst offenders are content sites, as opposed to merchants and identity sites
  • The reason is that content sites, which often don't even need passwords
    • Use them as an excuse to force registration and collecting of demographic data
    • Also to encourage further interaction with the site, driving more traffic
  • The problem is that while the security risk on a content site itself is low
    • The common practice of reusing passwords for many sites
    • Puts users at risk on other sites where security impacts are higher
  • For any given password that is re-used, its risk is as great
    • As the single most important site for which it is used
  • This is why I constantly recommend the use of random passwords
    • Coupled with a password vault
    • So you remember one password only ever used locally
    • Which unlocks distinct, high security passwords for use at each site
    • Personally, I still use Sxipper for this purpose
    • http://www.sxipper.com/
  • The paper had a silver lining, though, that sites with better security practices
    • Are growing faster than sites with poorer policies

(08:28) News

(08:39) Open source could make attackers' jobs easier

  • http://www.technologyreview.com/computing/25480/?ref=rss&a=f
  • I've talked recently about both programming language, operating system
    • And their lack of effects on security
  • Only the programming language story had data to back it up
    • Though the reasoning about operating systems was sound
  • Technology Review has an article discussing some new research
    • Which uncovered a correlation between open source
    • And speed and frequency of attack
  • Sam Ransbotham, assistant professor at Boston College's Carroll School of Management
    • Wrote the paper detailing the findings discussed in this article
  • He worked with a sizable amount of data, 400MM alerts
    • From intrusion detection systems correlated by software and vulnerabilities
  • The findings showed open source software being attacked three days sooner than closed counterparts
    • And with 50% higher frequency
  • The article has a lot more detailed about the data used in the study
  • Ransbpthan suggests the spread of attacks is the flip side
    • Of how innovation spreads using open source
  • His contention about attackers is that access to source
    • Lowers the cost of attack as there is more knowledge available
  • Robert Lemos who wrote this piece
    • Thinks this will reinvigorate arguments about which is more secure
    • From a practical perspective it does suggest that open source is less secure
    • Not as a function of code quality but of economics of attack
    • Lemos doesn't weigh in on one side or the other
      • And mentions the usual defense
      • That the relatively lower costs to analyze code
      • Also factor in the favor of defenders
  • I would go further and suggest that this study
    • May act as a prod to move programmers beyond thinking about specific exploits, fixes
    • It really drives home the point that processes need to support secure code
      • Regardless of whether it is open or closed
    • That is the only way that defenders can stand a better chance
      • Expecially when attackers have access to the same knowledge
  • Ransbothan mentions another piece of knowledge that he thinks yields a similar effect
    • That of vulnerability databases that include signatures of flaws in particular programs
  • For me, this encourages taking his paper with a grain of salt
  • It would be ridiculous to suggest that defenders not share information
    • The benefits far outweigh the risks that attackers will also use such databases
  • I think that informs a similar response to any conclusions about the effect of open source
    • On the likelihood of any flaw being exploited and how severely
  • Lemos quotes another security professional skeptical of Ransbothan's findings
  • Unfortunately, I am a bit confused as to whether this expert, David Aitel of Immunity
    • Should be credited and if so, how much
  • His company works on security closed systems
    • That would normally make you think he'd be inclined to agree with Ransbothan
    • But his remarks are largely dismissive of threats to open source
  • If you think about it, his bottom line is improved by a greater threat, real or perceived
    • To the closed systems he is responsible for defending
  • I think it is safest to say that while this study is interesting
    • It doesn't really offer any practical advice
  • We still need to follow vulnerabilities, keep systems patched, and practice secure coding
    • Regardless of whether the software we use is open or closed

(12:17) Understanding the real risks of Android fragmentation

  • http://arstechnica.com/open-source/news/2010/06/ars-explains-android-fragmentation.ars
  • As I explore moving away from closed systems, back to exclusively open ones
    • I am starting to track Android with more interest
  • I am hoping to find a small tablet running it but may have to bite the bullet
    • And finally upgrade my old, junky cell to an Android smart phone
  • My curiosity was piqued when I saw this Ars Technica post
    • Where Ryan Paul digs into the concerns
    • Over perceived or potential fragmentation in the Android market
  • Paul starts by defining fragmentation
  • In its simplest form, it is divergence of a bit of software
    • With variations spun out from an original
    • Usually through customization to meet some specific need
  • The risk is that the further variants diverge, the less likely they'll remain compatible
  • He uses the example of Linux, where distros often make different choices
    • For common components, like desktops, package systems, and versions of the same software
  • In the case of Linux, the problem is partly addressed by the distro makers
    • Application authors rarely have to deal much with fragmentation
    • Distro specific package maintainers work to ensure applications work as intended
  • The implication is that this does not hold true for the mobile space
    • Device makers are not the same as package maintainers
    • They might address some issues with the highest profile applications
    • But the independent developer is left in the cold
    • To struggle with compatibility across different versions of Android
  • It gets worse, as Paul explains, as the hardware platforms in mobile devices
    • Can be wildly divergent unlike relatively standardized desktops, servers, even laptops
  • Lastly, device makers often will customize Android further to stand out, be more attractive
  • One solution Google has is a compatibility definition
  • It lays out some minimum hardware standards that manufacturers must meet
    • But not to use Android, which is open and freely available
    • Rather they tie passage to access to the Android Market
    • A device that is too customized to muster cannot include the Market application
  • Requiring that key hardware is present, like touch screen, GPS, bluetooth
    • Means any developer looking to distribute through the Market
    • Can safely make certain assumptions about what resources
      • Will be on any device connecting to the Market to get their application
  • The other way Google encourages compatibility is their choice of software stack
  • Dalvik is a variant of Java with the same kind of portability
  • Even the Native Development Kit comes with conditions
  • A device matching the compatibility definition has to meet the NDK halfway
    • Provided standard interfaces and libraries
    • So native code can avoid many of the binary compatibility pitfalls native code would otherwise encounter
  • Paul also talks about the Intent system, which ties into the compatibility definition too
  • Intent has to do with how applications invoke each other
  • A vendor cannot replace a stock app with their own unless it matches the Intents supported by the stock application
  • So the real fragmentation issue, it turns out, has to do with the rapid iteration of Android itself
  • There are some affordances to hide incompatible applications from devices with older versions of Android
  • It is a big issue with developers, though, as the temptation to use the latest APIs
    • Comes with the risk of excluding older devices
    • Many of which are still accessing the Market according to Google's own stats
  • Paul doesn't think version fragmentation is going away any time soon
  • He actually makes a good case it is necessary to Android competing successfully with Apple
  • Ultimately, he is optimistic, that the newer, better versions are worth potentially stranding some early adopters
  • I also wonder if the hardware will stabilize even though the OS keeps evolving quickly
  • Think of the iPhone OS iterate on existing phones
    • Whatever you think of Apple, that has worked well up until 4
    • Largely because the hardware in question was relatively stable
  • For Android, any such effect may be a plateau, followed by a steep inclined
    • But any sort of leveling in the hardware so older devices can keep up
    • Will buy back some of the good will, at least, that was lost by the breakneck pace before

(17:17) Programmers should stop being smart-alecks

  • http://www.wired.com/beyond_the_beyond/2010/06/programmers-should-stop-being-such-smart-alecks/
  • Bruce Sterling points to a post on Wired
    • Written by what appears to be a battle worn, somewhat cynical programmer
  • It is actually a follow up post to one he wrote about super languages
  • The nut of that is there is a class of elite programmer
    • Who really don't care to do mere application programming and subsequent maintenance
  • Letting them use their favorite super language can convince them to pitch in
    • Unfortunately, the resulting code isn't maintainable by normal programmers
    • The subsequent rewrite of the super programmer's code reinforces their view
    • That they are elite and everyone else is a philistine
  • I don't think this is entirely unreasonable, if a bit over simplified
  • This post digs into the motivations of elitists
  • The author admits to formerly being one so has some room to talk
  • He points out a self-reinforcing attitude
    • Of already feeling intelligent for having learning programming
  • He further argues that a small increase in intelligence
    • Yields an exponential increase in programming capability
  • This is contrasted against attitude, by implication towards the work and results
  • He uses himself as a good example
  • The project that taught him this valuable lesson
    • Was a novel database heavily inspired by pure theoretics
  • It was compounded by implementing it as a multithreaded kernel extension
  • The difference in this case is he toughed it out
    • Compared to many uber developers who would sell or leave the company
    • When the grunt work of debugging and support kicked in
  • He spent twenty years trying to fix his mistakes
    • Ultimately moving the code to a new, more practical framework
  • He concludes that this attitude is rampant
  • Worse that it is the height of self indulgence
  • I love one of his concluding thought
    • "It is not about solving puzzles and being the brightest kid in the class. It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention."
  • This speaks to the very reason why I keep urging humility throughout the Inner Chapters
  • Part of his observations is that this behavior is endemic
  • Software development won't mature as a profession until that changes
  • Sterling for his part is understanding, supportive in his remarks
  • The only case where he disagrees is where the author suggests he might have been better off
    • Skipping the brilliant hacker stage and starting off as a practical minded "drudge" to use Sterling's term
  • Sterling thinks that is a paradox
    • The author never would have learned this lesson in such a deep way
    • He also thinks the author wouldn't have tried anything inspired
  • I think the truth lies somewhere in between
  • I don't think anyone is saying there isn't room for creativity, inspiration
    • But they have to be balanced by a practical streak
  • A sense of appropriateness also helps in terms of where to indulge the urge for the esoteric
  • Hacking up a prototype or personal project in an odd ball language
    • Is entirely appropriate and may even shed light on more practical concerns
  • When collaborating with others, trying to keep a sane release schedule
    • That is where the really wacky design choices are a problem
  • The author of the post is Jonathan Edwards
    • Who is currently working at MIT as a Research Fellow with the Software Design Group
  • That also gives some weight to his words, experiences

(21:02) Heated atomic force microscopes for 12nm graphene elements

  • http://arstechnica.com/science/news/2010/06/heated-atomic-force-microscope-makes-12nm-graphene-circuits.ars
  • Graphene is a material of considerable interest to researchers
    • Working on different physical media for use in electronics, computers
  • Like carbon nanotubes, graphene is a particular ordering of just carbon atoms
    • That leads to an amazingly high degree of conductivity
  • Graphene is a lattice of carbon atoms in a sheet only one atom thick
  • If it could be used in electronic components, it would lower power requirements and heat output
  • According to John Timmer at Ars Technica the hurdle to trying this
    • Is how hard it is to craft features in the graphene sheet
  • A sheet of uniform conductivity and resistance is useless to do work
  • Timmer explains a new paper published in Science
    • That builds on work with oxidizing graphene which lowers its conductivity
    • This is usually a chemical reaction that affects an entire sheet
  • The oxidization can also be effectively reduced, restoring conductivity
    • Through the mere application of heat, in a reducing reaction
  • The paper's authors experimented with more finely controlling the application of heat
  • In this case they used an atomic force microscope
  • They were able to essentially draw features in a sheet of graphene oxide
  • The channel they inscribed was a mere 12nm wide, incredibly small
    • Even for the realm of computer components
  • The implication is that a CPU built with this technique could pack transistors in very densely
  • I believe the current size of features on a CPU is around 32nm to 45nm
  • At this stage, a graphene die could yield more than a three fold improvement
  • The 12nm size is specific to this research, perhaps the scale could be improved further
  • These behaved very much like reduced graphene oxide, under very close testing and scrutiny
    • Offering low friction and high conductivity to an applied current
  • The result was like the tracing, inscribing or deposition of wires in traditional circuits
  • There was a difference in conductivity of four orders of magnitude
    • Demonstrating that the technique could lead to practical graphene circuits
  • The etching speed was decent, the researchers even envision a high speed rig
    • With multiple microscopes for etching wafers in a practical production mode
  • Timmer entertains the notion that the temperature based effects are permanent
    • That is not only could the graphene be altered during manufacture
    • But it may also be possible to apply heat, current in a running chip
    • His example is to use low current to just use a semi-conducting channel
    • Then applying a very high current to alter the graphene, fix a channel
  • Another advantage Timmer doesn't consider which the paper might have
    • Is that most semi-conductors require the use of toxic materials
    • A circuit made entirely of graphene would not put toxic metals into a land fill
    • Or require special handling and recycling
    • Undoubtedly the preparation of the graphene sheets wouldn't be all that green
    • But altering at least part of the ecological impact of electronics could be huge

(24:08) Following Up

(24:27) Another social network bill of rights

  • http://cfp.acm.org/wordpress/?p=341
  • Via Bruce Sterling
  • The site to which Sterling links is the blog for an ACM conference
    • Specifically, CFP, Computers, Freedom and Privacy
  • The post lays out a plan to draft a bill of rights at the next conference
  • EFF, who has already advanced a draft, has been represented at CFP in the past
  • Many of the panels cover the topics that should inform a draft
  • There is also room for an unconference one day to tackle topics not formally on the program
  • The suggestion actually makes a good deal of sense
    • Given the depth of history behind CFP
    • And the recent focus on users' rights in the wake of Facebook stepping on privacy
  • Towards the end of the conference, there will be a BoF
    • Held to put together a draft based on all the input
    • During the conference from attendees and from folks responding online
  • A broader effort might better attract the cooperation CFP is seeking
  • EFF is one voice, if other advocacy groups join in
    • As well as attendees from commercial sites, services
    • Then the idea might finally get some traction
  • As the post puts it, a well crafted bill could attract sites looking
    • To compete by affording users more, better rights

(25:59) Judge may dismiss most defendants from US Copyright Group suits

  • http://arstechnica.com/tech-policy/news/2010/06/judge-may-dismiss-4576-of-4577-p2p-defendants-from-lawsuit.ars
  • I've been following the US Copyright Groups campaign of mass demand letters and law suits
    • As the latest example in an emerging trend
    • Of monetizing infringement not directly by the rights holders or even intermediaries
    • But by parties looking solely to profit off of the potential of large statutory damages
  • Nate Anderson at Ars Technica has the first bit of possibly good news
  • US Copyright Group has been lumping thousands of defendants into each suit
  • EFF, others issued a brief to the courts protesting this practice
  • One judge, Collyer in the DC district, has pushed back
  • She gave USCG two weeks to convince her this joindering had merit
    • Otherwise she will dismiss the two cases against over 4000 defendants
  • If the judge severs the law suits, they'd have to re-filed independently
  • The only reason USCG is trying this is they think the cost to do so is low
  • If Collyer or any judge allows joining a single suit against so many
    • That will sustain those economics
  • If the majority of judges facing these cases act as Collyer has
    • It could tip the balance back, making it too costly for potential reward
    • Of statutory damages
  • This is not to say there ins't money to be made
    • In the form of people who simply chose to settle
    • But it may weaken the threat that would drive them to do so

(27:32) Outro

Retrieved from "http://www.thecommandline.net/wiki/2010_06_13"
Personal tools