Really everything related to technology
Time to submit some more strange emails I’ve received recently. Here’s one I suspect may be someone who spots that curl is being abused against some host. I really wouldn’t even know how to begin to answer this…
Someone is using your code to continually hack small businesses I work with. How on earth do I stop them?![name]
Why I insist on people to keep issues on the mailing list(s)
A recent twitter discussion I had with Andrei Neculau contributed to his blog post on this subject, basically arguing that I’m wrong but with many words and explanations.
It triggered me to write up my primary reasons for why I strongly object to handle open source issues, questions and patches privately (for free) in open source projects that I have a leading role in.
1. I spend a considerable amount of my spare time on open source projects. I devote some 15-20 unpaid hours a week for those communities. By emailing me and insisting on a PRIVATE conversation you’re suddenly yanking the mutex flag and you’re now requesting that I spend parts of this time on YOU ALONE and not the rest of the community. That’s selfish.
2. By insisting on a private conversation you FORCE me to repeat myself since ideas and questions are rarely unique or done for the first time. So you have a problem or a question that’s very similar to one I just responded to. And the next person will ask the same one tomorrow. By insisting on doing them in public already in the first email, already the second person can read it without me having to write it twice. And the third person who didn’t even realize he was interested in that topic will find out and read it as well (either now when the mail gets sent out or even years later when that user find the archived mailing list on the web). Private emails deny that ability. That’s selfish.
3. By emailing me privately and asking questions and help, you assume that I am the single best person to ask this question at this given time. What if I happen to be on vacation, be under a rough period at work or just not know the particular area of the project very good. I may be the leader or a public person of a project, but I may still not know much about feature X for operating system Z about which you ask. Ask on the list at once and you’ll reach the correct person. That’s more efficient.
4. By emailing me privately, you indirectly put a load on me to reply – or to get off as a rude person. Yes you’re friendly and you ask me nicely and yet even after you remind me after a few days I STILL DON’T RESPOND. Even if I just worked five 16-hour work days and you asked questions I don’t know the answer to… That’s inefficient and rude.
5. Yes, you can say that subscribing to an email list can be daunting and flood you with hundreds or thousands of emails per month – that’s completely true. But if you only wanted to send that single question or submit the single issue, then you can unsubscribe again quite soon and escape most of that load. Then YOU do the work instead of demanding someone else to do it for you. When you want to handle a SINGLE issue, it is much better load balancing if you do the extra work and the people who do tens or HUNDREDS of issues per month in the project do less work per issue.
6. You’re suggesting that I could forward the private question to the mailing list? Yes I can, but then I need to first ask for permission to do so (or be a jerk) and if the person who sent me the mail is going to send me another mail anyway, (s)he can just as well spend that time to send the first mail to the list instead of say YES to me and then make me do his or hers work. It’s just more efficient. Also, forwarded questions tend to end up so that replies and follow-up questions don’t find their way back to the original poster and that’s bad.
7. I propose and use different lists for different purposes to ease the problem with too many (uninteresting) emails.
In the middle of my otherwise happy summer vacation, my Nexus 10 had a serious case of depression and took a nose-dive from a little over a meter above floor level and crashed into the mighty fine stone tiles. It got some serious damage and there are cracks all over the screen.
A while ago I posted a service request on Samsung’s site to get it fixed (they manufacture the Nexus-10s and the device have a product number and everything in Samsung’s systems), and they responded and directed me to my nearest “quick support center” for screen and display repairs. The nearest one happens to be located just a few hundred meters from where I work these days.
Today I stepped in there and asked to get my screen fixed.
– “It’ll cost you some 2000-3000 SEK” one of the two service guys says at once. Clearly not really wanting to fix it.
– “Eh, that’s a bit unspecific. Can you tell me with some better accuracy?” I reply. After all, I didn’t pay an awful lot more than 3000 SEK for it as new – in the US and I wanted to figure out if a repair would be worth the money.
– “Okay”, he says and leaves the room through a door and is gone for a while.
– “Do you have the serial number for it?” the guys says returning and yeah, I brought it there in its original box and the serial number is there. The guy leaves again.
– “Did you buy that device here?” He’s back. Without really specifying where “here” means but I figured he means in Sweden so I of course had to tell him
– “No, it’s purchased in the US”
– “Then we can’t fix it.” and then he explains how they can’t order the parts necessary for the device and that’s it. Nothing to do. They can’t.
Okay, so I knew there’s always a risk when “grey-importing” so I’m not really very upset. I’m mostly baffled by their response and also by the fact that there apparently is something different with the Nexus 10 display if it was bought in the US – or at least they say so.
We still have another Nexus 10 in the family and I’m ordering a 2nd gen Nexus 7 now to replace this dead thing with…
A person unknown to me sent me this email. I don’t know why he/she sent this to me or how he/she thought I would be a person that can help out. The language used says machine-translation to me given some of the very weird language constructs used.
It doesn’t look like a scam nor spam to me. A mystery.
Dear,
Kindly I need your support and help is very urgent isse, I have account in Skype has been Hacr today by
[the name used here is withdrawn, possibly a nick name or skype account name?]
And Introduced me two syllables where I speak to him and introduced me the names of people I know where the deployment section as well as my wife threatened to publish pictures where I’m not sure that happened, my family pictures
I hope you help me solve the problem so as not being destroyed my family life, and to take the necessary measures and inform the authorities as I have known it from Qatar
Please call me for confirmation for help on 123-0123456789
A brand new libcurl security advisory was announced on April 12th, which details how libcurl can leak cookies to domains with tailmatch. Let me explain the details.
(Did I mention that security is hard?)
curl first implemented cookie support way back in the early days in the late 90s. I participated in the IETF work that much later documented how cookies work in real life. I know how cookies work, and yet this flaw still existed in the curl cookie implementation for over 13 years. Until someone spotted it. And once again that sense of gaaaah, how come we never saw this before!! came over me.
When cookies are used over HTTP, it is (if we simplify things a little) only a name = value pair that is set to be valid a certain domain and a path. But the path is only specifying the prefix, and the domain only specifies the tail part. This means that a site can set a cookie that is for the entire site that is under the path /members so that it will be sent by the brower even for /members/names/ as well as for /members/profile/me etc. The cookie will then not be sent to the same domain for pages under a different path, such as /logout or similar.
A domain for a cookie can set to be valid for example.org and then it will be sent by the browser also for www.example.org and www.sub.example.org but not at all for example.com or badexample.org.
Unless of course you have a bug in the cookie tailmatching function. The bug libcurl had until 7.30.0 was released made it send cookies for the domain example.org also to sites that would have the same tail but a different prefix. Like badexample.org.
It might not be obvious at first glance how terrible this can become to users. Let me take you through an imaginary story, backed up by some facts:
Imagine that there’s a known web site out there on the internet that provides an email service to users. Users login on a form and they read email. Or perhaps it is a social site. Preferably for our story, the site is using HTTP only but this trick can be done for most HTTPS sites as well with only a mildly bigger effort.
This known and popular site runs its services on ‘site.com’. When you’re logged in to site.com, your session is a cookie that keeps getting sent to the server and the server sometimes updates the contents and sends it back to the browser. This is the way millions of sites work.
As an evil person, you now register a domain and setup an attack server. You register a domain that has the same ending as the legitimate site. You call your domain ‘fun-cat-and-food-pics-from-site.com’ (FCAFPFS among friends).
Mr evil person also knows that there are several web browsers, typically special purpose ones for different kinds of devices, that use libcurl as its base. (But it doesn’t have to be a browser, it could be other tools as well but for this story a browser fits fine.) Lets say you know a person or two who use one of those browsers on site.com.
You send a phishing email to these persons. Or post a funny picture on the social site. The idea is to have them click your link to follow through to your funny FCAFPFS site. A little social engineering, who on the internet can truly resist funny cats?
The visitor’s browser (which uses a vulnerable libcurl) does the wrong “tailmatch” on the domain for the session cookie and gladly hands it off to the attacker site. The attacker site could then use that cookie to access site.com and hijack the user’s session. Quite likely the attacker would immediately change password or something and logout/login so that the innocent user who’s off looking at cats will get a “you are logged-out” message when he/she returns to site.com…
The attacker could then use “password reminder” features on other sites to get emails sent to site.com to allow him to continue attacking the user’s other accounts on other services. Or if site.com was a social site, the attacker would post more cat links and harvest more accounts etc…
End of story.
For every security vulnerability a project gets, it should be a reason for scrutinizing what went wrong. I don’t mean in the actual code necessarily, but more what processes we lack that made the bug sneak in and remain in there for so long without being detected.
What didn’t we do that made this bug survive this long?
Obviously we didn’t review the code properly. But this is a tricky beast that was added a very long time ago, back in the days when the project was young and not that many developers were involved. Before we even had a test suite. I do believe that we have slightly better reviews these days, but I will also claim that it is far from sure that we would detect this flaw by a sheer code review.
Test cases! We clearly lacked the necessary test case setup that tested the limitations of how cookies are supposed to work and get sent back and forth. We’ve added a few new ones now that detect this particular flaw fine, but I think we have reasons to continue to search for various kinds of negative tests we should do. Involving cookies of course, but also generally in other areas of the curl project.
Of course, we’re all just working voluntarily here on spare time so we can’t expect miracles.
My “landline” phone in my house is connected over voip through my fiber and I’m using the service provided by Affinity Telecom. A company I never heard of before and I can only presume it is a fairly small one.
Everything is working out fine, apart from one annoying little glitch: every other month or so my phone reports itself as either busy to a caller (or just as if nobody picks up the phone) and the pingcom NetPhone Adapter 201E voip box I have needs to be restarted for the phone line to get back to normal (I haven’t figured out if the box or the service provider is the actual villain).
In my household we usually discover the problem after several days of this situation since we don’t get many calls and we don’t make many calls. (The situation is usually even notable on the voip box’s set of led lights as they are flashing when they are otherwise solid but the box is not put in a place where we notice that either.) Several days of the phone beeping busy to callers is a bit annoying and I’ve decided to try to remedy that somehow. Luckily the box has a web interface that allows me to admin it and check status etc, and after all, I know a tool I can use to script HTTP to the thing, extract the status and send me a message when it needs some love!
Okay, so I just need to “login” to the box and get the status page and extract the info for the phone line and I’m done. I’ve done this dozens if not hundreds of times on sites all over the net the last decade. I merrily transferred the device info page “http://pingcom/Status/Device_Info.shtml” with curl and gave it a glance…
Oh. My. God. This is a little excerpt from the javascript magic that handles the password I enter to login to the web interface:
/*
* Get the salt from the router
*/
(code gets salt from a local URL)
var salt = xml_doc.textdoc;
/*
* Append the password to the salt
*/
var input = salt + password;
/*
* MD5 hash of the salt.
*/
var hash = hex_md5(input);
/*
* Append the MD5 hash to the salt.
*/
var login_hash = salt.concat(hash);
/*
* Send the login hash to the server.
*/
login_request = new ajax_xmlhttp("/post_login.xml?user=" + escape(username) + "&hash=" +
escape(login_hash), function(xml_doc)
[cut]
Ugha! So it downloads a salt, does hashing, salting and md5ing on the data within the browser itself before it sends it off to the server. That’s is so annoying and sure I can probably replicate that logic in a script language of my choice but it is going to take some trial and error until the details are all sorted out.
Ok, so I do the web form login with my browser again and start to look at what requests it does and so on in order to be able to mimic them with curl instead. I then spot that when viewing that device info page, it makes a whole series of HTTP requests that aren’t for pictures and not for the main HTML… Hm, at a closer look it fetches data from a bunch of URLs ending with “.cgi”! And look, among those URLs there’s one in particular that is called “voip_line_state.cgi”. Let me try to get just that and see what that might offer and what funny auth dance I may need for it…
curl http://pingcom/voip_line_state.cgi
And what do you know? It returns a full XML of the voip status, entirely without any login or authentication required:
<LineStatus channel_count="2">
<Channel index="0" enabled="1">
<SIP state="Up">
<Name>0123456789</Name>
<Server>sip.example.org</Server>
</SIP>
<Call state="Idle"></Call>
</Channel>
<Channel index="1" enabled="0"></Channel>
</LineStatus>
Lovely! That ‘Idle’ string in there in the <Call> tag is the key. I now poll the status and check to see the state in order to mail myself when it looks wrong. Still needs to be proven to actually trigger during the problem but hey, why wouldn’t it work?
The final tip is probably the lovely tool xml2, which converts an XML input to a “flat” output. That output is perfect to use grep or sed on to properly catch the correct situation, and it keeps me from resorting to the error-prone concept of grepping or regexing actual XML. After xml2 the above XML looks like this:
/LineStatus/@channel_count=2 /LineStatus/Channel/@index=0 /LineStatus/Channel/@enabled=1 /LineStatus/Channel/SIP/@state=Up /LineStatus/Channel/SIP/Name=012345679 /LineStatus/Channel/SIP/Server=sip.example.org /LineStatus/Channel/Call/@state=Idle /LineStatus/Channel /LineStatus/Channel/@index=1 /LineStatus/Channel/@enabled=0
Now I’ll just have to wait until the problem hits again to see that my scripts actually work… Once proven to detect the situation, my next step will probably be to actually maneuver the web interface and reboot it. I’ll get back to that later..
Back in October 2006, we added support for HTTP pipelining to libcurl. The implementation was naive and simple: it basically preferred to pipeline everything on the single connection to a given host if it could. It works only with the multi interface and if you do a second request to the same host it will try to pipeline that.
Over the years the feature was bugfixed and improved slightly, which proved that at least a couple of applications actually used it – but it was never any particularly big hit among libcurl’s vast amount of features.
Related background information that gives details on some of the problems with pipelining in the wild can be found in Mark Nottingham’s Making HTTP Pipelining Usable on the Open Web internet-draft, Mozilla’s bug report “HTTP pipelining by default” and Chrome’s pipelining docs.
Now, more than six years later, Linus Nielsen Feltzing (a colleague and friend at Haxx) strikes back with a much improved and almost completely revamped HTTP pipelining support (merged into master just hours before the new-feature window closed for the pending 7.30.0 release). This time, the implementation features and provides:
The code also adds a feature that helps out applications to do massive amount of requests in a controlled manner:
A hard maximum amount of connections, that when reached makes libcurl queue up easy handles internally until they can create a new connection or re-use a previously used one. That allows an application to for example set the limit to 50 and then add 400 handles to the multi handle but it will still only use 50 connections as a maximum so over time when requests get completed it will start new transfers on the requests that are waiting in line and thus shrinking the queue and keeping the maximum amount of connections until there’s less than 50 left to do…
Previously that kind of queuing had to be done by the application itself, but now with the much more extensive pipelining support it really isn’t as easy for an application to know when the new request can get pipelined or create a new connection so this logic is now provided by libcurl itself. It is likely going to be appreciated and used also by non-pipelining applications…
This implementation is accompanied with a bunch of new test cases for libcurl (and even a new HTTP test server for the purpose), and it has been tested in the wild for a while with libcurl as the engine in a web browser implementation (the company doing that has requested to remain anonymous). We believe it is in fairly decent state, but as this is a large step and the first release it is shipped with I expect there to be some hiccups along the way.
Two things to take note of:
In the end of January 2013 we got a fresh security vulnerability pointed out to us in the curl project (it was publicly announced on Feb 6). Another buffer overflow. This time in the SASL Digest-MD5 handling for POP3, IMAP and SMTP. It is the 16th security flaw during curl’s life-time of almost 15 years so it isn’t a disaster but still of course it is never fun when it happens. I put a lot of my own effort and pride into this project so every time something like this floats to the surface my pride and self-esteem get damaged a bit.
Everyone who’s concerned about open source and security and foremost in a reliable and secure libcurl of course now wonders: how did this happen? How could this piece of security problem get into libcurl and what are we doing to make sure it doesn’t happen again?
Let me tell you the story. It is not as interesting nor full of conspiracies as you’d like. It is instead rather dull and boring but nevertheless the truth.
I’m the lead developer and maintainer of curl and libcurl. I personally have done some 65% of all commits in the project and I do the majority of all code reviews on the mailing list. Our code might be used by some 500 million users, but the number of regulars that can be considered the “core team” can still basically be counted on a single hand. Also, we all do this primarily on our spare time.
During intense development periods we get flooded by bug reports and patch submissions and my backlog grows. It’s really not possible to foresee when these periods come, but occasionally it seems the planets align in this way and work piles up.
In order to then proceed the best way in the project, I try to focus on the architectural and “deep” matters that need me and my particular knowledge most. I then try to leave the “easy” problems that are easier to work on to others, and I try to stay away from the issues that already seem to be under control by some of the existing regulars in the project. I also have to let other “elders” in the project push things with slightly less scrutiny just to be able to plow through the work better. Unfortunately this leads to the occasional flaw getting through and in this case it was even a security vulnerability that when you look back on the code you really cannot understand how we could miss this.
We do take security seriously though and we make a big effort on handling all security reports swiftly and accurately. Even if this was the 16th time we let our guard down, I want to think that we at least react responsibly and in a good way when we realize our mistakes.
Please don’t judge us due to this. Please instead consider joining us and help us review code and help us find the next flaw before we merge it into mainline or at least before we do a public release with the code!
About two years ago I purchased my Desire HD made by HTC, which has indeed been a trusted work horse of mine. Even if does lack on the battery side and the micro USB connector has gotten a bit worn out so that most cables fall out unless I take precautions to avoid it.
Back then I upgraded from an HTC Magic to a rather high end device of the time. This time the bump goes like this in pure specs/numbers, and it is interesting to see how two years have changed the scene…
HTC Desire HD: 164 grams, 123 x 68 mm and 11.8mm thick. 4.3″ LCD
Nexus 4: 139 grams, 133.9 x 68.7mm and 9.1 mm thick. 4.7″ LCD
Two years ago many people asked me about the “big” phone and had objections. Today, that old 4.3″ thing is small in comparison. As you can see, the Nexus 4 is basically “only” a centimeter taller than the old one, while a bit thinner and much lighter. The extra centimeter and the removal of the bottom buttons basically gave the extra screen reel estate.
PixelsHTC Desire HD: 800 x 480
Nexus 4: 1280 x 768
Roughly 2.5 times the number of pixels on screen.
HTC Desire HD: 1230 mah
Nexus 4: 2100 mah
70% more battery juice. Should come handy but won’t stop me from dreaming about some real battery evolution!
CPU: 1GHz single core is now a 1.5GHz quad-core.
RAM: 768MB of RAM has now grown to 2GB.
Price: The price on this new phone is lower than the old one as new!
Buttons: I find it interesting that I’ve gone from 6 buttons, to 4 to none through my three Android phones.
HTC Sense vs Stock Android: I’ve never been particularly upset with Sense, and now when the Desire HD is stuck on Android 2.3 and Nexus runs 4.2 they feel very different anyway.
A feature my HTC phone has and that I like, but that stock Android lacks is the ability to completely block (ignore) certain contacts on incoming calls. I can add sales people or telemarketers and then completely not see 
them at all, no matter how many times they phone me – not even as missed phone calls.
One thing I’ve actually been slightly annoyed with in the Desire HD is its really crappy camera. I believe the Nexus 4 camera has the same amount of pixels but I do have hopes that it’ll allow me to take better pictures while being out and about.
I figured this posting wouldn’t be complete without also include a picture of my first Adroid phone, the HTC Magic.
I held off this long but now I’ve joined the
tablet owning part of the world. I brought home my new and shiny Nexus 10 yesterday (purchased in the US, it is not yet available to buy in this dusty and dark corner of the world).
Android 4.2 on a 10 inch 2560×1600 screen is a lovely experience. It is the 16GB wifi-only version. Did I mention that the screen is awesome?