Archive for March, 2010

dude, i got a dell (actually, several of them)

Wednesday, March 31st, 2010

If you failed to notice, my site is probably loading much faster now. I’ve recently bought several Dell PowerEdge servers and bought one for personal use… seeing as the old box was 4 years old and already blew several drives and a PSU (and infact, only had one PSU), it seemed like a good idea to phase it out.

In other news, it takes a long time to copy a 20GB virtual machine image from a degraded RAID-5 array…

As an update to the previous post, well, MSKs tend to get leaked earlier than expected. There’s already a couple of custom firmware payloads for the PS3 that are signed and working already using the leaked MSK allowing the loading and execution of unsigned code. Note that I don’t condone piracy so I’m not going to open the pandora’s box of linking to those firmwares. They exist, you know how to use a search engine, but stealing people’s work sucks.

As an aside, I would like to point out that security models built on trust only work when you don’t consistently remove features during your product’s lifecycle.  If you remove features during a product’s lifecycle, then there becomes motivation for people to break the security model.  The only reason why people didn’t break the PS3′s security model earlier is because the Other OS feature allowed execution of “homebrewed” games and demos.

Sony “Software Assurance Signing Keys” to be released April 1

Monday, March 29th, 2010

Since Sony is an enemy of freedom now, it’s time to release the hypervisor security keys.  Since Sony cannot change these as they are burned into the IPL ROM which starts the supervisor SPE up, PS3 security is about to be non-existent.  Can we say custom firmware?  We sure can.

I can’t wait for the DMCA on this.

conspire is dead; long live conspire (or is it?)

Friday, March 26th, 2010

As many of you already know, I have been experimenting with quassel for the last couple of months.  Quassel is a very decent client, but it’s simply not for me.  As a result, I’ve been thinking about the future of Conspire.  Here is what I have decided:

Work will begin immediately on Conspire 2.0

Conspire 2.0 will be built ontop of the latest additions to the atheme platform, such as mowgli.coroutine and libneco.  These additions will allow us to increase our stability and reliability without having to worry about implementation details in the client.  However, mowgli.coroutine has not been mainlined yet, so this will be a couple of weeks out.

Usage of mowgli.coroutine and libneco are already planned for the next atheme-services release to improve robustness and performance of that software.

Modularity

Conspire 2.0 will be reworked to place the RFC1459+extensions/IRC3 protocols in the plugins space, so that other plugins may be implemented, such as a libpurple interface.  This allows the conspire user to manage all of his chat activities from a single application with a consistent interface.

This will be achieved through ensuring that everything in the core is cleanly hooked, and then moving most of the core into the plugin space.  In addition, many parts of the core will be replaced with code from atheme-services, including the xchat IRC line parser.

DCC Support

DCC support will likely be dropped.  DCC is a horribly designed protocol plagued with many security problems.  This will also allow us to drop our UPnP code.  Users should use services like Omploader and Rapidshare if they wish to share files over IRC.

Support for IRC 3.1 client profile features

Support for IRC 3.1 client profile features like RENAME will be added.  This will ensure that Conspire remains at the leading edge of IRC protocol development.

…it’s the TSA’s lucky day.

Friday, March 26th, 2010

Someone finally went and said it: breast implants can be used to blow up jet airplanes, so women with them should be given extra security screening.

What was that I just heard?  Oh yeah, the sound of almost every male TSA agent on the planet going “fuck yeah!”

On another note, I’ve been getting hate mail and hack attempts on my website for having the gaul to say that hpHosts is bullshit.  Many of these are written by idiots who think I am not involved in the security industry.  News flash: I’m involved in the security industry, in a way that actually matters, so haha.  Also, ApplianceKit 1.0 public release coming shortly.

hpHosts is bullshit

Tuesday, March 23rd, 2010

No, really. So, apparently my website was listed in hpHosts because I had an archived copy of PSYB0T on my server so that people could analyze it.  To get it removed, I was forced to remove that content.  What a joke.

What makes it worse is that the guy who runs hpHosts is involved as a contributor to DroneBL, which linked to the malware and specifically said it was an archived version.

He had the gaul to call himself a member of the security community, even though a quick google of him only reveals a bunch of posts on spyware forums and dnsbl mailing lists.  People like him are the reason why the security community needs to stop doing crystal meth.

Also, fun fact: hpHosts is hosted on a bespoke SOHO ADSL line.  Haha.

Why Atheme no longer works with InspIRCd when m_invisible is loaded

Monday, March 22nd, 2010

As of a couple of days ago, we put some checks in designed to block casual usage of the m_invisible module in InspIRCd on Atheme-running networks.  As certain InspIRCd contributors view this is a troll, I would like to explain why we are in fact quite serious about this.  The remainder of this post will be split up into two sections, explaining why m_invisible is morally unacceptable, and why m_invisible is impossible to enforce in Atheme anyway without complicating the code base extensively.  The remainder of the post after that will include a point-by-point rebuttal of some of the more amusing things that contributor has said in the last day.

The moral argument for removing m_invisible from InspIRCd

The module in InspIRCd named m_invisible.so allows you to join channels invisibly and spy on the users.  Granted, there are plenty of other methods that allow this, however m_invisible makes it accessible to the average user who is unaware of the other options.  In other words, this means that it makes this wholesale spying capability available to at least 80 percent of InspIRCd’s userbase.

Consider for a moment, a situation where users trust their network staff, but the network staff have recently done something to make them upset, so the owner of the network joins the channel and starts watching people vent.  Since he is watching them vent about whatever it is that he has done, he gets angry and starts placing autokills against his users.  While it is the administrator’s service, and he has every legal right to do so, it is not an ethical or moral thing to allow happen.

Another scenario, which has recently happened, is that an IRC server was infiltrated by the Chinese secret police.  Many users on this IRC server were monitored without consent using m_invisible, resulting in at least two people being apprehended due to participating in dissent activities.  If you don’t know how the Chinese secret police operate, I’ll summarize it: those people are most likely dead now.  While this scenario is not directly the fault of m_invisible and the surveillance could have been implemented in other ways, m_invisible was the simplest way to implement it, which brings me to another point, if you have to enable this module on your network, make sure you trust your staff entirely.

I brought this last point up with Brain, the project leader of InspIRCd after he flamed me on MSN due to the changes I implemented.  He did not seem to be affected by the fact that there are now two people most likely dead over events that happened during IRC surveillance, and accused me of being the “moral police”.

Moral police or not, those people died because of the fact that InspIRCd made it possible to easily spy on them.  While it is possible that they would have died anyway, the method that was used to intercept their communications was provided as a module in InspIRCd.

Ultimately, to us, we view this as a moral question.  Because Atheme is a middleware used on many InspIRCd networks, we felt that we had the need to stand up and say “we don’t want our software used in this specific configuration.”   Regardless of whether or not you agree with our position, it is our right to politely ask our users to comply with that.  There is nothing in the license forbidding the usage of Atheme in this specific configuration, so if you want to remove the checks, then that is your own business, but at least make sure the staff you have on your network are respectable.

Why m_invisible will never work correctly with Atheme

Now on to the technical reasons of why Atheme no longer works in this configuration: it is impossible to support the configuration properly without changes that the developers are unwilling to make due to code correctness and the moral issues outlined above.  As an example, if you place the *!*@* mask on +V in the channel ACL, it will auto-voice the invisible user when they join.  If you feel the network you are on is spying on you, but you cannot leave, we recommend that you place *!*@* on autovoice, which will expose the invisible users.  You can also kick the users if you can guess their nickname.

The technical reason is grounds enough to disable support for m_invisible in Atheme.

Counterpoints

13:34 <~Brain> hes doing it the same reason hes always stirred up trouble, to get publicity for atheme and charybdis.

The IRC community generally knows that I don’t actively market Atheme or Charybdis, and allow them to stand on their own merits without the necessity of spamming, doing SEO or anything else.  Atheme’s popularity stems from our reputation of code correctness and realistic feature support.

13:32 <~Brain> Taros: then i say that your view of irc is very closed minded and restricted only to the public-network views that youve seen, havent you ever seen a closed support network? they log *everything* for accountability.

Professional support desks typically use Kayako LiveResponse, which is not built on top of IRC at all.  InspIRCd plus an IRC client does not come anywhere near the capabilities of Kayako, period, so it seems unlikely that anyone would use it for this purpose.

11:14 <~Brain> hmm, i could fork it.

There are plenty of other Atheme forks out there, so good luck!