Posted by Scott Laird
Wed, 19 Mar 2008 01:19:00 GMT
So, one of the features that’s been in the WebKit tree for a while but finally showed up in Safari today is downloadable font support. You can use CSS to apply a specific font to an element and Safari will download the font from a URL provided.
That’s really cool, but the odds of an exploitable buffer overflow somewhere in the font rendering pipeline has to be almost 100%. I mean, almost every graphics format has had multiple exploitable bugs on every platform, and I can’t see how a complete OpenType renderer can be any less complex than JPEG. Even worse, this is a new attack vector, against a part of the system that wasn’t part of the security perimeter before. Is there a way to turn this off?
Tags fonts, safari, security | 1 comment
Posted by Scott Laird
Wed, 15 Aug 2007 16:16:00 GMT
I mentioned last week that I’ve been working on building sort of a lightweight home security system for my house so my 4-year-old daughter won’t be able to sneak out of the house again.
I spent about a day researching possible solutions, to see if there was something simple that I could buy that would make me happy, and I couldn’t find anything on the market that was cheap and would tell me which of my 6 exterior doors had been opened loudly enough to hear from across the house. There’s no point in putting a door buzzer on the basement door if you can’t hear it from the master bedroom. The only solutions that I found were from professional alarm companies, and they probably would have charged me a couple thousand for installation plus $30-$50 per month for monitoring. I’m just not willing to pay that much, and it’s not really what I was looking for–it’s gross overkill for my problem.
So, I decided to build it myself. After a few hours’ searching, I decided to use Perceptive Automation’s Indigo home-automation software for the Mac. It’s commercial software, but I like its user interface and capabilities better then any of the open-source solutions that I’ve seen. It’s under active development, supports just about everything that I need, it’s client-server so I can access it from any Mac I own, and it comes with a nice web interface that I can get to via my phone. I figured that it’d be cheaper to pay the money for Indigo then to spend most of a week hacking away at one of the open-source packages to get them to do what I want. Plus, er, pretty much every open source home automation program that I could find was written in Perl, and I’ve been successfully avoiding Perl for almost 5 years now. The last thing I really want to do is spend a week modifying someone else’s Perl. That kind of thing gives me nightmares.
So I fired Indigo up on an old Powerbook that I had laying around and bought a bunch of hardware from MacHomeStore and SmartHome.com. The important bits are a W800RF32A wireless reciever and a whole bunch of $12 DS10a door and window sensors. The sensors broadcast their state over the air, and the receiver feeds them into my Mac.
That took care of the input side of the equation, but I still needed some relatively cheap way to play audio around my house. I poked around for a while looking at random X10 hardware and radio solutions before I realized that most VoIP phones support audio paging. Since my house is full of VoIP phones and I run my own Asterisk server, all I’d really need to do was write a couple dozen lines of Asterisk dialplan code, and everything should just work. I ended up ordering two new VoIP phones (Grandstream GXP-2020s) because two of the phones that I have are too old to be usable for paging. I probably could have used $45 Budgetones, but I have future plans for the GXP-2020’s big displays, so I decided to spend a bit more for them.
It took me about 30 minutes to unpack everything, install Indigo, and have it receiving data from a test sensor. Each sensor assigns itself a random 8-bit ID when it’s powered up, so the first problem was mapping semi-random sensor IDs onto logical names. Indigo comes with a blob of sample AppleScript for doing this, and it only took me 5 minutes to modify it so that one of Indigo’s internal variables changed state to reflect the state of the door sensor–true when the door is closed and false when opened. Five more minutes and I had a nifty web page with a green blob that turned red when the door opened. A half-hour after that, I had a PNG floorplan of my house that I could use as a backdrop for a bunch of little red/green blobs:
After this, it’s all just a matter of plumbing. First, I modified Indigo’s sensor-handling AppleScript example into something that knows how to talk to Asterisk, using one of the Asterisk/AppleScript integration examples on the voip-info.org Wiki. Here’s I ended up with:
(*
Door sensor tracking code for Indigo and Asterisk.
By Scott Laird <scott@sigkill.org>
http://scottstuff.net
This code handles incoming security events, maps each numeric
device ID onto a logical name, and then tells Asterisk to page all
VoIP phones with a device-specific message.
Net effect: opening the front door causes "Front door opened" to echo
throughout the house.
I'm calling doDialOut directly rather then using an Indigo trigger for 4
reasons:
1. I have the extension name handy here, while I'd have to parse it back out of the variable name if I used triggers.
2. Creating an identical trigger for each of 10+ sensors is a pain in the neck.
3. We need to do *something* with unknown sensor events, but creating variables for them is pretty clearly wrong.
4. My AppleScript is lousy, and I can't get triggers to call doDialOut correctly.
*)
using terms from application "IndigoServer"
on receive security event of eventType with code devID
set extension to "unknown"
-- Map sensor IDs onto logical names. In a real language,
-- I'd use some sort of hash and skip the if ... else if ... code,
-- but I don't see anything suitable in AppleScript. Sigh. I'm
-- stuck writing code in blub.
if devID is 95 then
set extension to "frontdoor"
else if devID is 175 then
set extension to "deckdoor"
else if devID is 99 then
set extension to "stairs"
else if devID is 201 then
set extension to "backyard"
else if devID is 55 then
set extension to "upgarage"
else if devID is 155 then
set extension to "downgarage"
else if devID is 253 then
set extension to "slider"
end if
-- If we get a request for an unknown devID, then send it on to Asterisk
-- so we get an audible indication that *something* happened. Since batteries
-- falling out of DS10 modules can cause the ID to change, I'd rather not ignore
-- these. YMMV, however.
if extension is "unknown" then
my doDialOut(devID)
else
-- Indigo variable names are derived from Asterisk extension names.
-- In retrospect, doorClosed_ is a great name for doors, but not so hot
-- for doorbells or motion sensors. Feel free to change this.
set var to ("doorClosed_" & extension)
set seen_var to ("lastSeen_" & extension)
set change_var to ("lastChanged_" & extension)
set timestamp to (current date) as string
-- Figure out if it opened or closed. There are actually 4 different
-- results that the sensors can return (normal/active X min/max),
-- but we only care about normal/active.
if eventType is sec_SensorNormal_min then
set val to "true"
else if eventType is sec_SensorNormal_max then
set val to "true"
else
set val to "false"
end if
-- Create the Indigo variables if they don't already exist.
if not (variable var exists) then
make new variable with properties {name:var, value:val}
end if
if not (variable seen_var exists) then
make new variable with properties {name:seen_var, value:timestamp}
end if
if not (variable change_var exists) then
make new variable with properties {name:change_var, value:timestamp}
end if
-- Did the value of this variable just change?
if not (value of variable var is val) then
set value of variable change_var to timestamp
-- If it just changed and it's now false, then send an alert.
-- The DS10a sensors send a signal once per hour, even if nothing's changed.
-- So we don't want to alert *unless* something's changed.
if val is "false" then
my doDialOut(extension)
end if
end if
-- We need to keep track of the time that each DS10 was last seen.
-- This way we can spot bad batteries.
set value of variable seen_var to timestamp
set value of variable var to val
end if
end receive security event
-- doDialOut tells Asterisk to dial a specific extension using
-- Asterisk's management interface. This doesn't require that Asterisk
-- runs on the same machine as Indigo.
--
-- To get this to work in your environment, you'll need to change the IP
-- address, username, and password, and possibly the contexts and/or
-- extension names used at the bottom.
on doDialOut(extension)
log "Paging extension " & extension using type "Dialer"
set expectscript to "set timeout 20;
spawn telnet 10.0.0.1 5038;
expect \"Asterisk Call Manager/1.0\";
send \"Action: login
username: my_username
secret: secretsecret
\";
expect \"Message: Authentication accepted\";
send \"Action: originate
Exten: " & extension & "
Context: security-paging
Channel: Local/all@paging
Priority: 1
Callerid: Security: " & extension & " <0>
\";
sleep 1;
send \"Action: logoff
\";
"
set results to do shell script "/usr/bin/expect -c '" & expectscript & "'"
end doDialOut
end using terms from
In addition to simply monitoring the current state of the sensors, this also tracks their last change as well as the last time each sensor sent out a “nothing’s changed” report. Eventually I’ll add monitoring for this so I can spot failing batteries immediately, and not two months later when I discover that two doors aren’t monitored anymore. Indigo tracks each variable internally, and gives you a handy window for viewing and modifying them:
Once all of that was in place, it was time to add paging logic to Asterisk. I created two new contexts, security-paging to contain the messages that need to be played back and paging to handle the phones. The AppleScript above basically glues the two ends together, sending ‘deckdoor@security-paging’ to ‘all@paging’. Here’s the relevant bit of my Asterisk config:
[security-paging]
exten => frontdoor,1,Playback(security/frontdoor)
exten => deckdoor,1,Playback(security/deckdoor)
exten => backyard,1,Playback(security/backyard)
exten => stairs,1,Playback(security/stairs)
exten => upgarage,1,Playback(security/upgarage)
exten => downgarage,1,Playback(security/downgarage)
exten => slider,1,Playback(security/slider)
exten => _.,1,SayNumber(${EXTEN})
[paging]
exten => all,1,Page(Local/203@paging&Local/204@paging&Local/205@paging&Local/206@paging)
; Cisco 7940; no Call-Info support, but you can create a new line and turn on auto-answer on the phone.
exten => 203,1,Dial(SIP/203aa)
; Sipura 841. It needs a semicolon before answer-after.
exten => 204,1,SipAddHeader(Call-Info: \;answer-after=0)
exten => 204,n,Dial(SIP/204)
; Grandstream GXP-2020s, although the same config will work for most modern phones.
exten => 205,1,SipAddHeader(Call-Info: answer-after=0)
exten => 205,n,Dial(SIP/205)
exten => 206,1,SipAddHeader(Call-Info: answer-after=0)
exten => 206,n,Dial(SIP/206)
Then I just had to record some audio files to use for annoucements. The easiest way to do this is just to call yourself up and leave voicemail, and then copy the VM files over into Asterisk’s sound file directory, usually /var/lib/asterisk/sounds. You could get better quality recordings with a good microphone and audio-processing app, but I’m not sure that there’s really a point, given the quality of most speakerphone speakers.
All told, it took me about 8 hours of research to put this all together, and maybe 10 hours to implement it all, including learning a bit of AppleScript. Now I have a programmable system for monitoring my house, and all of the pieces in place for adding X10 or Insteon components as they make sense. It’s all under my control; if I can code it, then I can make it happen.
So, does it all work? Yep–Monday morning it caught my daughter trying to sneak into the garage. Mission accomplished.
Tags asterisk, home, indigo, insteon, security | 12 comments
Posted by Scott Laird
Thu, 07 Jul 2005 23:46:19 GMT
CNet says that there’s a security bug in zlib 1.2.2. There’s no exploit yet, but since everything uses zlib, this will probably turn into a problem for those who don’t upgrade to 1.2.3 once it becomes available.
Since libpng and OpenSSL both use zlib, we’re going to see a lot of network-based programs with issues.
Posted in Computer Security | Tags linux, openssl, security, zlib | no comments
Posted by Scott Laird
Tue, 17 May 2005 20:13:57 GMT
Bruce Schneier posted a link to an AES timing attack from Dan Bernstein.
This is similar to last week’s hyperthreading vulnerability, in that it exploits cache timing variances to extract sensitive information, but DJB’s attack is demonstrated working over a network–it doesn’t require that the attack code run on the same physical CPU as the encryption code. Instead, it exploits the fact that AES implementations need to do data-dependent lookups from tables, and the tables don’t fit entirely into the CPU’s fastest cache. Therefore, by closely watching the time it takes for a server to encrypt a packet and return a result, you can learn something about the key itself. By feeding the server millions of carefully-crafted packets and examining the timing results produced, he was able to narrow the keyspace substantially.
In this case, he was able to recover all 128 bits of a randomly-generated AES key in around a day. Most likely, the process could be optimized substantially by testing high-probablility keys against a known plaintext in parallel with the AES. I wouldn’t be surprised if an hour’s worth of traffic was enough to narrow the keyspace enough to make a brute-force attack possible. His notes also suggest a number of other optimizations that may lower the amount of work even further.
In general, any data-dependent timings anywhere in a crypto system will subject the system to this sort of problem. Unfortunately, it’s nearly impossible to eliminate all of the data-dependent timing issues on any modern computer–between cache issues, hidden optimizations in certain instructions, measurable delays when switching between cache banks, and an utter lack of comprehensive performance documentation, there’s really no easy way to avoid this class of problems on modern CPUs. The best you can do is minimize the amount of variance and force the attacker to use larger and larger amounts of traffic.
All in all, this probably isn’t just a theoretical attack. It isn’t something that random hackers will use, but it’s fast enough to be usable by a determined attacker with relatively low-latency network access to the victim’s system.
Posted in Computer Security | Tags aes, cryptography, djb, security, timingattack | no comments
Posted by Scott Laird
Fri, 13 May 2005 00:27:44 GMT
KernelTrap is reporting that a SFU grad student has found some sort of hyperthreading vulnerability. Details are slim, but he’s claiming some sort of information leakage between threads on a HT CPU, saying that this could lead to the disclosure of things like RSA private keys.
If I had to guess, I’d say that this is some sort of timing attack. Most likely, the leak occurs when one HT thread runs a predictable chunk of code with secret data while the other HT thread runs some sort of monitoring code, watching for things like cache misses or utilization of the various shared resources. Or maybe, Intel shares the CPU performance counters between the two threads so the attacking thread can simply extract detailed timing information from the other thread’s work, and then use the timing information to reconstruct details on what the attacked thread was doing. There’s a decent body of work on attacking smart cards using similar techniques.
Update: After doing a bit of research, it looks like Intel does share performance counter data between threads, and some of the data shared is really interesting, like branch prediction data–if you’re attacking a known body of code, you may actually be able to extract enough data from this to get a decent peak at the private key.
Update 2: The paper is online. If I’m reading this correctly, the basic attack uses timing measurements against the L1 and L2 caches to see when the RSA thread moves on to a new cache line worth of data. The attack doesn’t need access to anything more advanced then the CPU’s cycle-counter clock to be able to recover roughly 310 bits from a 512 bit key.
Personally, I find this to be fascinating from an academic standpoint but not terrifically useful in the real world. I don’t generally want untrusted users to have any access to systems with valuable keys. Historically, it hasn’t taken most attackers very long to turn untrusted shell access into a root exploit. In almost any case, a root exploit is more worrying then the loss of 310 bits from a 512 bit key–if the attacker had root, odds are they could recover the entire key directly.
This is clearly a problem that needs to be fixed by Intel, but I’m not planning on running around disabling Hypertheading on all of my systems today. It’s just not that dangerous of an exploit for most users.
Posted in Computer Security | Tags cryptography, security, timingattack | no comments
Posted by Scott Laird
Thu, 28 Apr 2005 18:20:56 GMT
Phil Windley says that Visa and Mastercard are starting to crack down on small merchants, requiring them to meet some sort of minimum information security standards or lose the ability to accept Visa or Mastercard purchases online. This is clearly a good thing.
He lists 12 basic requirements:
- Install and maintain a working firewall to protect data
- Keep security patches up-to-date
- Protect stored data
- Encrypt data sent across public networks
- Use and regularly update anti-virus software
- Restrict access by “need to know”
- Assign unique ID to each person with computer access
- Don’t use vendor-supplied defaults for passwords and security parameters
- Track all access to data by unique ID
- Regularly test security systems and processes
- Implement and maintain an information security policy
- Restrict physical access to data
The actual questionnaire from Visa goes into a lot more detail (“Do changes to the firewall need authorization and are the changes logged?”). A quick skim of the questionnaire shows a bit of Windows bias (you can’t pass unless you have virus scanners on all your servers–that’s kind of weird in a Unix environment), but it looks like a great step forward. It’s nice to see someone in a position of influence raising the security baseline.
Posted in Computer Security | Tags cryptography, mastercard, security, standards, sysadmin, visa | 1 comment
Posted by Scott Laird
Wed, 16 Feb 2005 19:10:17 GMT
I’m not an expert in cryptography, but I try to pay attention to what’s happening in the crypto world. Today, Bruce Schneier announced:
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.
The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have been quietly circulating a paper announcing their results:
- collisions in the the full SHA-1 in 269 hash operations, much less than the brute-force attack of 280 operations based on the hash length.
- collisions in SHA-0 in 239 operations.
- collisions in 58-round SHA-1 in 233 operations
So, unless I’m mis-reading this, SHA-1 lost a factor of 2,048; that’s enough to start moving away from SHA-1, but not enough to run screaming in the streets. The last time that SHA-1 attacks showed up, similar attacks were possible against MD5 and possibly also the newer SHA family members; I’m not really sure if there are cryptographic hashes in common use that aren’t at least slightly tainted right now.
Posted in Computer Security | Tags broken, cryptography, security, sha1 | 5 comments
Posted by Scott Laird
Mon, 25 Oct 2004 15:45:31 GMT
According to The Register, Cisco is currently adding encryption abilities into their phones and call manager software. The article’s kind of hard to follow–it claims that the 7960G currently has encryption support, which is news to me–but the general gist is that they’re planning on adding some sort of direct VPN support into most of their phones via software upgrades.
Knowing Cisco, the feature will be implemented in some odd manner (L2TP+1DES IPsec in the phone?) and will only work with the CallManager-specific SCCP image for the phones, not the SIP image.
On the other hand, if they actually added TLS/SSL support for SIP and SRTP, then that’d be a huge motivation for getting encryption in Asterisk.
Posted in Asterisk | Tags asterisk, cisco, cryptography, security, voip | no comments
Posted by Scott Laird
Tue, 08 Jun 2004 21:45:06 GMT
Boing Boing has a link to a Bruce Schneier story in Computerworld that talks about the ’Witty’ worm from March 2004. This was the first that I’d seen about Witty, but it sounds freakishly scary: it was targeted on ISS’s BlackICE/RealSecure intrusion-detection systems. It was released under 48 hours after the vulnerability in BlackICE was made public. It infected 100% of the vulnerable systems on the net in 45 minutes. It was launched from a coordinated set of ‘drone’ machines. And it slowly destroyed the systems that it infected by overwriting random blocks of their hard drives.
Fortunately, there were only 12,000 vulnerable systems on the net. This time. The problem is that the code for Witty is out in the wild now. It’s only 700 bytes long, and it should be easy for an attacker to modify it to fit the next UDP exploit that shows up. Can you imagine what would happen if this blew through 20 million Windows boxes?
This might be a good time to run backups.
Posted in Computer Security | Tags security, virus, windows | no comments
Posted by Scott Laird
Fri, 24 Oct 2003 18:35:19 GMT
Amazing–a book on role-based access control. Enhanced security models like RBAC and MAC have been making their way into Unix and Linux for years, but I still haven’t found a good introduction to either model. Maybe this is finally it. The Linux Journal reviews it:
A good overview of implementing RBAC in the enterprise for students as well as corporate-level decision makers. [Linux Journal]
Amazon has it for $79, or £55 from amazon.co.uk.
Interestingly enough, the UK Amazon has an ebook on HIPAA and RBAC that I didn’t see when searching on amazon.com. That’s strange because HIPPA is a US thing, not a UK thing. I’m not particularly interested in HIPAA, though, and I prefer paper books.
Posted in Books, Computer Security, Computer System Administration, Work | Tags books, rbac, security | 1 comment
