August 14, 2009 at 10:41
· Filed under Politics ·Tagged bad, Ballymore Properties, corruption, cronyism, debts, Dr. Peter Bacon, entitlement, Fianna Fail, NAMA, Peter Bacon, property
It seems Dr. Peter Bacon, the man who Fianna Fail turned to for an answer to the property-loan banking crisis and who has come up with NAMA is a bit of an academic shill for hire:
The cost of the report to Longford County Council was around €25,000-€30,000. … A substantial portion of this was contributed by an anonymous donor — believed to be Longford-born builder Joe O’Reilly.
He is, of course, a long-standing beneficiary of contracts from FF governments:
Close to former Taoiseach Bertie Ahern, his economic consultancy, Peter Bacon & Associates, picked up a steady stream of public contracts even after the Government’s change of tack on housing policy.
The best part is that he has had, extensive interests in property development companies himself. If he does not hold shares still (unusual for board members to not be compensated with shares), then he certainly must have many friends in an industry that will no doubt be a source of revenue to him again in the future:
Peter Bacon … former board member of Ballymore Properties, one of the property developers now in the spotlight,
So the plan to have all the bad property loans offloaded to the Irish state was invented by a man who quite probably is a Fianna Fail crony amd a man who besmirches his academic title through shilling. A man who definitely has very close ties to the property developers.
Why are we letting Fianna Fail “fix” this problem with this destructive plan? Why don’t the Greens walk out and let the country vote?
(And yes, I’m a bit late to this revelation)
Permalink
August 13, 2009 at 12:12
· Filed under Politics ·Tagged banks, Buiter, credit-crunch, debt, Green Party, Ireland, loans, NAMA, property, rescue
Based on my layman’s reading of various articles out there, here’s my rough but hopefully representative guide to rescuing banks:
Good <---------------------------------------> Bad
re-capitalise do overpay
through nothing massively for
equity bad debts of
investment unknown value
On the left-hand side is rescuing banks by the state investing in equity (i.e. buying shares) and potentially acquiring it completely (nationalisation) to later spin-off the good bits back into private ownership (Buiter’s “good bank”) and wind-down the bad bits. This approach has been tested before in Sweden’s banking crisis, and is currently working quite well in the UK.
On the right-hand side is where you overpay the banks massively for bad debts, with no more than a vague promise that you might try recover some of the losses in levies if the losses are too huge, and where you get no stake in the future profits the banks will make thanks to your rescue. I.e. NAMA (or SCAMA?).
“Oh, but do you really want the governments to run a bank?” – Well, do you want the government to (part-)own an existing bank through shares, or do you really prefer the government to have to setup from scratch an agency, complete with political appointments, to directly manage a very big lump of loans and property?
It seems only Green Party members can save us.
Permalink
August 7, 2009 at 09:29
· Filed under Politics ·Tagged boycott, Iran, Juan Cole, neocon, nutshell, sanctions, sociopaths
Juan Cole has this in his recent piece on Neocon desires to ratchet up sanctions on Iran:
Neoconservatives, whether Christian or Jewish, whether Bolton or Rubin or Clawson, are sociopaths who lack the basic ability to empathize with people not exactly like themselves, and who exalt instrumental goals over basic human welfare.
+1
Permalink
August 4, 2009 at 21:27
· Filed under Technology ·Tagged buffer, censorship, Eclipse, filtering, internet, ISP, IWF, overflow, risks, Security, Squid
CVE-2009-2621 was released last week. The issues seem to include a buffer-overflow, which implies a potentially easy remote root shell exploit1. So it’s perhaps worth repeating my previous claim that Squid really should not be used for security sensitive applications.
This is not to take away from Squid. As the swiss-army knife of web-caching/proxying software it’s awesomely valuable software. It’s just that building for security is somewhat at odds with software intended to be highly flexible and featureful.
Even if Squid’s code were 100% defect free managing its default feature-set remains a significant security problem. E.g. my own ISPs’ Squid-using Pædosieve still honours CONNECT to anywhere, proving just how hard it is to configure such software to disable unneeded features – and they were made aware of the problem many months ago. Prior to that they had forgotten to lock-down access to the internal in-band management protocol (accessible by using CONNECT proxying to localhost). They only recently disabled SMTP on the Pædo-sieve, possibly because they received email sent through it via the Squid proxy.
1. The bug report mentions this is triggerable via ESI, which I don’t think is relevant to a Pædo-sieve, but as it was in some generic string storage code there may well be many other paths to the bug.
Also, bugs were found in the HTTP header parser, where it will assert if fed a very large header. Relying on assert() is somewhat fragile, as these can be disabled by the compiler. Indeed, the fix for the ESI buffer overlow is to add an assert, it seems. Not confidence inspiring, security wise at least.
Permalink
July 28, 2009 at 10:57
· Filed under Security, Technology ·Tagged encryption, hygiene, password, Security
In a hypothetically perfect world, we’d be able to remember infinite numbers of passwords. However, for most people that’s not possible. Instead we have to find a way to make best use of that limited memory. Here’s how:
- Do not use passwords that are easy to guess, e.g anything directly related to you, like your name or names of family/friends/pets/etc; or date of birth; or favourite colour,band,etc..
- Ideally, use a longish random string as your password, of at least 10 characters (but longer is better).
- The same applies for password-recovery questions, which often ask for information that is in the public domain (e.g. mother’s maiden name, date of birth). Do not provide real answers! Instead just make something up, or use another random string if possible.
- Do not re-use passwords across different websites, unless you truly do not care about what is on those sites, and what they can do in your name with that password.
- Do not be afraid to write them down if you can store them securely. E.g. if your home is reasonably secure, it’s fine to store most passwords on paper there. This goes against advice from many well-meaning, but utterly-wrong “experts”.
- If you trust that a computer or device is sufficiently secure, it’s perfectly fine to store passwords on it, e.g. in a text-file. Also, many programmes support saving passwords and if you trust those programmes then it’s perfectly OK to use those features.
- Consider using disk-encryption products like PGPDisk, TrueCrypt, BitLocker or the built-in capabilities of many Linux/Unix distributions (some of which offer this at install time) to protect your data with a master key. This is particularly recommended for laptops.
- Any computer running Microsoft Windows likely can not be considered secure and should not trusted with more sensitive information. Portable devices should not be considered secure, unless their contents are known to be encrypted, and they automatically lock themselves after a small period of unuse (i.e. don’t trust your phone too much for storing sensitive data).
Basically, in an ideal world, all your day-to-day passwords for your various, online accounts should be unguessable, random strings; you’d never have to remember any of them; you would just, at certain times, have to enter a master pass-phrase (which should be unguessable, but still memorable and much longer than a password) without which the passwords would effectively not be accessible.
Remember, security is a compromise between convenience and consequence. The ideal level of compromise will differ between different people, and between different situations. E.g., obviously, it’s probably a good idea to tolerate a good bit of inconvenience with your online banking login details and commit these solely to memory. If you have too many accounts to memorise the details, then store them very securely, e.g. buy a strong box or small safe, and obscure which details belong to what accounts – hopefully this buys enough time to contact banks and have the details changed if your house is burgled and the box stolen.
Common sense goes a long way. Unfortunately the “experts” you sometimes hear from don’t always have it.
Permalink
July 15, 2009 at 15:14
· Filed under Technology ·Tagged attack, caches, DNS, harmful, kaminsky, poison, Polyakov, QID, sharing
Eircom have been having problems with internet connectivity. It’s hard to get information about exactly what they’re seeing, but there seem to be 2 aspects to it:
- Eircom are getting hit with a lot of packets
- Customers have sometimes been directed to strange sites by Eircom’s DNS servers
Justin Mason has a good overview of the news coverage. There some points of his worth correcting though:
I.e. DDoS levels of incoming DNS packets are consistent with a poisoning attack on up-to-date DNS servers, which randomise QID.
The moral of the story here is that using recursive, caching DNS servers that are shared on any significant scale, like ISP nameservers or (even worse) OpenDNS, is just unhygienic. They’re just fundamentally flawed in todays internet environment, as they’re juicy targets for poisoning, until DNSSec is widely deployed. When finally DNSSec is deployed, shared, recursive nameservers remain a bad idea as they terminate the chain of the trust – the connection between the NS and client can still be spoofed.
In short:
- Technical users and systems admins should install local, recursive nameservers. Preferably on a per-system basis.
- Operating system vendors should provide easily-installed recursive nameservers and should consider installing and configuring their use by default. (Fedora provides a convenient ‘caching-nameserver’ package, and also a new dnssec-conf package with F11, though not enabled by default).
- Consumer router vendors already ship with recursive servers, but tend to forward queries to the ISP – they should stop doing that and just provide full recursive service (hosts already do caching of lookup results anyway).
Widely shared, recursive nameservers are a major security risk and really should be considered an anachronism. It’s time to start gettting rid of them…
Permalink
July 8, 2009 at 15:33
· Filed under Technology ·Tagged defunct, email, harmful, lists, mail-followup-to, Reply-To
Dear Interwebs,
If you happen to have responsibility for some software that processes mail, please take the time to check the following:
- That your software always errs on the side of preserving the Reply-To header, when passing on email. E.g. email list software in particular should not overwrite existing Reply-To headers, even if a list is configured to set a default Reply-To.
- That your software can process Reply-To headers that have multiple email addresses.
- That your software provides adequate, interactive cues to its user when they reply to an email, so as to discern what the user wants, in the context of what the sender prefers (so far as that is known).
- If your software supports various weird, non-standard headers, like Mail-Followup-To, Mail-Copies-To, Mail-Replies-To, etc. deprecate and remove this support. No amount of extra headers can obviate the need for the cues in the previous point – all they do is make the situation worse overall.
- If your software must support these headers, do not let such support cause the standard and well-supported Reply-To header to be automatically ignored.
If you’re a user of software that honours Mail-Followup-To and/or has buggy Reply-To behaviour, please file bugs and/or send them patches.
So why are Mail-Followup-To et al harmful? The answer is that they increase the number of ways that the wishes of the sender, the respondent and the state of the email may interact. What was already a tricky and murky area is made even murkier when you try add new ways to indicate the desired reply-path. E.g. witness Thunderbird’s help on MFT, or Mutt’s help on Mailing lists. I defy anyone to be able to keep all the rules of their MUA behaves in the presence of the various combinations of Reply-To, From, To, Cc, Mail-Followup-To and Mail-Reply-to in their head. For the few who can, I defy them to keep track of how their MUAs support interacts with the support in other MUAs.
Further, Mail-Followup-To has never been standardised. The header is described in DJB’s Mail-Followup-To and the dead IETF DRUMS draft. Both specs effectively say that the absence of MFT when a client does a “followup” reply should continue to go to the union of the From address (From == From or Reply-To), To and the Cc. However, these descriptions carry little authority. Unfortunately Mutt, one popular MUA, behaves differently when in list-reply mode and does not fallback to (From|Reply-To)+To+Cc in the absence of MFT – at least when I last investigated. This means Mutt basically does not inter-operate with other MUAs, when it comes to the standards-track means of indicating Reply preferences.
Before we had the problem of trying to get a few cases of bugs in broken Reply-To handling fixed (e.g. lists that blindly over-write Reply-To) + the UI design issues of figuring out where a user intends replies to go, without annoying them. Now we’ve added the problems of fractured interoperability with new same-but-different headers + the problems of bugs and deviations in the implementations of said new same-but-different headers.
Mail-Followup-To == more mess == even more brokenness.
See also: Archived DRUMS discussion on Mail-Followup-To.
Permalink
Older Posts »
