For what is almost certainly a few cosmetic touches to an existing app (that is likely only a couple hundred lines of code to start with) that would take probably 15 minutes to do, you'd charge $150k without any warranty of working, and then basically charge enough to nearly dedicate one reasonable (entry level) full time employee to an app that probably isn't used at all about 11 months out of the year? Well I know who is likely to lose any bids I put out for development work if that is indicative of your overreaction across the scale of things. Admittedly, I wouldn't raise this much fuss over this trivial case to even solicit bids (if it is really simple as I suspect it is, do it in the time it would take to go through the procurement dance).

I've seen quotes from a very good development company that has always delivered come in at about $10k for work significantly harder than this subject. Admittedly I think the owner undercharges for the skill of his team, but they seem happy because they knock it out in a week, deliver solid results, and move on to the next customer. So far my code review of their work has never seen a structural problem (some subjective preferences about some word choice was all) and the work hasn't actually produced defects for my test team or my clients. This is an example of *way* cheaper than it should be, but it helps provide some perspective on how unreasonable the numbers you throw out are. Of course, even with that they still get underbid, but we know better than to go to lowest bidder almost any time.

Yes, this is what I struggle with as well. It sounds like a trivial sort of application and the submitter characterizes it as needing a pool of developers and project management investment. That is a silly assumption, some things are truly trivial things. I had a very simplistic script on a backed up, shared filesystem and did 'git init' because it was essentially a free thing. Upon noticing that I bothered to git init, suddenly people were pushing 'you can't do git without something like github or gitlab, and an issue tracker, but not gitlab or github, but it needs to have integration with those'. Of course I know full well that it's a 20 line script for internal use by a team of about 5-6 people for a very trivial thing, and that those people aren't going to bother with a ticket even if a system was made available and instead just turn around in their cube and ask the entire user community about it.

As you say, this can go both ways, people stubbornly insisting on do-it-yourself and people pushing for 'someone else do it' against all reason. I have seen projects that really could use those facilities above and try to whip up their own gitlab type facility rather than just installing gitlab.

Not knowing all the details, I'm thinking I might concur here.

For one, you can either coast by on the current solution so long as it continues to accommodate the needs or completely change over now 'just in case' needs evolve in the future. The latter frequently is a bad move since you are taking a hit now either way for the sake of a nebulous future requirement that you can't even be certain will be met by your selected solution. This means that if that nebulous future comes to pass, you might have to migrate again and have saved nothing. If the current system works and the events are basically run the same year to year with only cosmetic tweaking, then it would be a waste to change.

For another, it seems like some people are afraid of having the littlest piece of software written in-house. Sometimes a solution really is simple enough that it's overkill to fret overmuch about maintenance and adaptability. Of course a key line to recognize is when you have evolved unexpectedly into the domain where worry is warranted, but a fairly simple facility to manage 1,400 records seems like it could reasonably fit into the realm of simple code that shouldn't be scary. I admittedly have more experience in corporate, but I imagine this holds true in a general sense. I've seen some companies outsource every little need to an unmanageable sea of vendors and get stuck with an overall atrocious experience and I've seen others stubbornly write everything in-house against all reason, so a balance must be struck.

Sure, that will get malware authenticated for that session. Realistically speaking, if the end device is compromised to the degree of having malicious intervening software, there's little that may practically be done. However, 'keylogging' does much less in this case. It can intercept the one time credential that was sent, but that credential is useless beyond that session.

Compare that to the common state of the art where not only can malware run amok with the authenticated session, it can also report up the login credentials for the adversary to use at will.

Now I will say I'd just as soon use TOTP with a pin appearing on my cell phone than a dongle. I suppose some people can't be bothered to type a 6 digit number in 60 seconds.

Actually, vendors actually do manage suppliers differently and rule out the cheapest frequently. There are companies that will do whatever is chepest no matter what, but they generally learn their lessons. For example many companies did this and counterfeit capacitors screwed them royally in terms of perception and warranty cost. The vendors that managed suppliers with a focus on quality laughed all the way to the bank.

Also, ironically Lenovo manufactures some devices in North Carolina, USA. Two parts of their stated strategy are distributed manufacturing and in-sourcing manufacturing rather than relying heavily upon companies like Foxconn the way most others do it. So you order Dell from US, you 100% won't have US manufactured stuff. You order Lenovo, you might get US manufacturing. Lenovo might give it up like Dell did, but at the moment if you want 'made in america' your best bet is Lenovo.

That was blackberry's biggest mistake. When it was blatantly obvious that their device market share was doomed, they could have swooped in and provided trusted enterprise platform atop the other platforms. Instead they stubbornly ignored that potential and doubled down on fighting back with dubious 'consumer' product, and failed.

So in the handset space, Lenovo can focus more on the efforts like BBM for other platforms. This could be a challenge since by the time Blackberry started responding, other credible competitors have seeped in (Microsoft, IBM, et al).

There is of course another interesting asset. Blackberry owns QNX, and QNX actually has a notable chunk of automotive.

Of course the rumor suggests a price in the neighborhood of 7.5 billion. That would be ludicrous for these options. They paid 1 billion for IBM's PC, 2 billion for IBM's x86 servers, and about 3 billion for motorola. It's hard to imagine enough perceived opportunity in Blackberry to be worth more than all of Lenovo's other acquisitions combined.

Except they just divested themselves of the division that does hardware based on other chips. Basically they sold to GF and probably required that GF would continue fabricate POWER for some time before renegotiating in a more traditional fashion. Maybe they are hoping that nVidia or some other companies will start designing serviceable POWER architecture chips and then they can sit back, and be like ARM without actually commissioning any actual chips and also sell servers based on the platform (or Tyan starts pushing out boxes they can slap an IBM logo on and skip designing servers either)

I think it's unlikely to go the way they are hoping for, but then again I never would have guessed Intel would have been able to get significantly into the Android ecosystem, so strange things can happen.

The 'topmost tiers' are threatened by other tiers, even when they are not direct replacements. Workload might not have another viable closed-source DB or Unix player or Mainframe platform to move to, but many of those workloads are moving out of those tiers entirely instead. On the flip side, you don't see a lot of workload living happily outside of IBM's wheelhouse eager to jump in. The signs all suggest that IBM's most believable favorable outcome is slowing the erosion rather than capturing a lot of new growth. This wouldn't be such a terrible thing, except that their business leaders and shareholders think that no growth == dead and act accordingly.

Considering the reality of the manufacturing and supply chain of *all* the vendors, there isn't a scenario where you are justified in not worrying on that score. The nationality of the CEO doesn't really help or hurt the ability of intelligence agencies to infiltrate product development and manufacturing.

Well, perhaps some of my comment should be modded down, but I really want people to cringe if they find themselves ever typing backtick, popen, or system() when doing web development, exploit or no exploit. It's just a very bad thing to do only as a very last resort in a very controlled situation.

No, only CGI programs that use system/popen/etc to call out to things that may be bash.

Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale. For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.

The DHCP case is truly a bad situation.

I still say that people shouldn't be using things like system() in cgi context except in very limited hacked up internal-only little web pages. It has the same problem as using bash directly, it's a massive waste of resources for an HTTP request to spawn a new process.

And while that underscores the appropriate need for this to be fixed, it should also be an opportunity to educate people to be wary of popen or system. If you leverage those a lot in a cgi context, you have created a significant potential bottleneck to scaling, versus using language libraries to accomplish the same goal without fork/exec being mandatory.

I guess the point is that if a significant application is either written in bourne script or even doing something like system() to do nearly anything and it isn't some internal low security thing, then there is something that is bad going on.

That's not to say the bash thing isn't bad, but it *should* also be a wake up call to people to be mindful of invoking external utilities willy nilly when it is not appropriate.

Ok, perhaps I undermined the importance, but if you are using 'xzgrep' in cgi context in a serious situation, I would say that is still a mistake. Forking and execing in response to an http request is terrible performance wise before getting to the security dubious of it all.

The dhclient-script stuff is pretty significant and I think I would be in a weak position saying that those have no business execing system commands/scripts. However it does suggest it may be worthwhile to have a helper that is non-root with capabilities to allow it to do key stuff to limit it's ability.