Hacker News new | past | comments | ask | show | jobs | submit login
Dump these insecure phone adapters because we're not fixing them, says Cisco (theregister.com)
42 points by PeterCorless on May 5, 2023 | hide | past | favorite | 33 comments



> Security hole ranks... 0 out of 10 in patch availability

Seems like this is because the product already had its software maintenance "end-of-life" in June 2020 [1]. Though it was also being sold up to that date, which seems bizarre that you could buy a product that would be "end-of-life" the very next day. Also, it continues to receive hardware support for another 5 years (through May 2025).

I understand that companies can't provide security updates infinitely for old products, but I have a hard time seeing logic for not providing updates when they're still under a hardware support contract. Seems like something should either be supported or not, not in an insecure in-between state.

[1] https://www.cisco.com/c/en/us/products/collateral/unified-co...


I don't work with Cisco kit but it certainly seems like they are hostile in the support realm. Even if you buy something used and there are software patches available for it you can't get them without a support contract for example. Stories like this "something serious is wrong and Cisco says get rid of it" seem fairly common as well. They must be damn amazing at what they do because these support stories would have me looking elsewhere.


Heh, I had some Cisco gear, from a company Cisco bought. It would crash under certain conditions. They gave me the "we need a support contract" line. I said I didn't need support and don't need new features. I just wanted it work as advertised, they didn't budge. I emailed a mailing list of other large site admins to not buy Cisco. Next morning I had 2 support folks and an account manager on the phone the next morning, they got me my patch.

The idea that you need support for things to work as advertised is insane.


The dirty secret I learned was to find out the name of the firmware file that fixed your issue, and then search for that via various means.

The other thing I realized was that our stupid support contract for some dinky router happened to give us access to any firmware file they had if you knew where to look ...

I assume they've fixed that second one.


I hear they did, but if you know a guy with a support contract on the same model...


The prevailing opinion on /r/networking is that cisco is trading on reputation and position, like a tank rolling forward with all the crew dead. Competitors matched their features years ago and cisco has been unable to innovate due to crippling technical debt in legacy product lines (build system is: find Nancy and ask her to compile with her version of this feature) and glaring deficiencies with their Firepower successor line.

That's my potted sentiment analysis, anyway


I don't think this is wrong. Question is how much time does "nobody gets fired for buying IBM" buy you?


At least when I was dealing with them, if you DID have a support contract (we had one for our phone system) they would move hell and high water to get it working, whatever it took.

Which is why this "we won't do shit no matter what" attitude is a bit surprising; often they'd have a firmware available for long-dead devices that was only available via support (or very sketchy Russian websites).


My work has completely changed over their telephony technology at least three times in 10 years. My parents had the same bakelite Western Electric phone on the kitchen wall for over three decades. Our defintion of technological advancement seems to be shorter-lived, throwaway stuff that compromises our privacy and demands frequent replacement. And the pace of obsolescence seems to be accelerating.


Same here. And what's amazing is that it never fixes anything. I've been in the software industry well over ten years, and been at companies that had multiple meeting room overhauls, and yet meetings regularly still start with the same crap about the AV equipment not working: host not sure if they're presenting, microphone feedback loops, etc. It's like we're running completely in place.


We need a new word that means "Hello, can you hear me?" and one that means "Hi, yes we can."


Syn/ack

:-P


Now I imagine my boss joining whilst I am repeatedly saying sin sin sin and another coworker is just as actively saying ack ack ack like bill the cat.


Note your parents seem content to pay month after month for wired phone service, most of which seems to be "extra fees".


I think a company needs a solution that’s a bit more involved than an analog phone screwed to a wall.


True. I've used the ATA190 that's recommended as a replacement. Pretty slick little piece of equipment. We had a copper pair supplying dial tone to an analog phone fail, but our fiber was fine. The little box talked to the PBX using SIP and supplied 2 analog ports. Got us through Winter until we could dig up and replace the copper plant.


Allows unsigned firmware to be uploaded, eh? Sounds like an opportunity to flash the phone with our own open source firmware. Even better if it fixes the remote exploit.


> while the last date to extend or renew a service contract for the product isn't until August 2024, Cisco said in the advisory it will not release firmware updates to address the flaw and there are no workarounds.

Why does Cisco get to take/keep people's money for service contracts when they don't provide the service?


I'd just guess that all of Cisco's customers are organizations that can do one-off negotiations (e.g., complain to sales rep, have lawyer write nastygram), and normally don't want to get involved in addressing the problem for everyone (by, e.g., complaining to government officials, raising a fuss on social media)?


Also see: Cisco SPA112 2-Port Phone Adapters Remote Command Execution Vulnerability [Listed as "Critical" "No workarounds available"]

https://sec.cloudapps.cisco.com/security/center/content/Cisc...


> This vulnerability is due to a missing authentication process within the firmware upgrade function. An attacker could exploit this vulnerability by upgrading an affected device to a crafted version of firmware.

> There are no workarounds that address this vulnerability.

Just crack the thing open and hard-wire the Write-Enable line to high and you’re good.

Here’s a tear down: https://goughlui.com/2016/02/14/review-teardown-cisco-spa112...

And here’s the data sheet to the flash chip:

https://www.mxic.com.tw/Lists/Datasheet/Attachments/8448/MX3...

Pin18

Voilà, enjoy your discount SPA112s!

(Or set pin19 write-protect to GND, can probably do that without even cutting a trace. Pin 20 is “NC” and might be wired to GND anyway so blobbing the two together might do it).


I suppose another workaround is to firewall every IP everything except your SIP provider's range and your local subnet. Probably a good idea for all ATAs unless you actually need to web-admin it externally.


https://www.cisco.com/c/en/us/support/unified-communications...

Interesting:

Release Date 29-AUG-2011

End-of-Sale Date 01-JUN-2020

End-of-Support Date 31-MAY-2025


Looks like a lineage from Linksys, which is a subsidiary known for once-ubiquitous WRT54G. IP phones from Cisco proper are much different, and I wouldn’t be surprised if they didn’t have build environment for this one ready to go.


These came from Sipura, which Linksys bought.

The last time I had some in service, they were responsible for connecting landlines for FAX and 911 service. (This was before VOIP exchanges had E911 availability and while FAX was still a viable protocol for signed documents.)


Things like this are why "signed, approved boot chain from power on to end user application" for all digital devices is currently in the "yes, it's happening, and here's why it's a good thing" phase.


Back in the earlier days of Android phones, it was fun to burn custom ROMs to try community-developed interfaces. This community was always upset when phone manufacturer's made it more and more difficult to do this. However, I think I'm understanding that this "signed, approved boot chain from power on to end user application" for all digital devices" is necessary for security purposes and would hopefully make it impossible to burn a custom ROM onto a phone.


You can satisfy both if there's a physical connection on a chip somewhere that you have to manually cut to disable the secure boot option - that leaves clear physical evidence that you did it, and would satisfy the free software types.


...No, that would satisfy the "We don't want to support these people" crowd. Full end user control over the secure boot chain, or GTFO.

Nothing less is acceptable. Corporates will never do it however, because they're up to their elbows in "deliberately not implemented".


“Real” Cisco phones like those behind President Zelenskyy on magazine covers take .cop.sgn files, and can deal with SSL-VPN, encrypted media and/or signaling, IPv6, device certificates, etc. those features with a guard on duty usually suffices. It’s available if you need it and are willing to pay for, and freemium version is just coming later.

(They’re EOL too and on eBay dirt cheap. I don’t know if my calls are actually encrypted but it can be fun to burn a weekend trying to register it to FreePBX)


Cisco phones are rough even with CUCM as the central server. They freeze randomly when connected to CUCM, to the point that its a pastime to walk into an office and look at the time and date shown onscreen on all the frozen Cisco phones.

Note that this freezing issue primarily affects phones made in the last decade from Cisco.


CUCM was originally developed by Selsius and never really felt like a "Cisco-quality" product.


This feels like it should be illegal




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: