Live data from Hacker News

AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

aisle.com

91–100 of 116 posts

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#91

OpenEMR? Used by some missionary doctor in remote Afghanistan?

Right. You're not a real medical group unless you go through an 18-month RFP procurement cycle including being wined and dined by the Epic rep who already knows they're gonna get your $50MM wallet because they're golf buddies with your CEO and already embedded with all your labs. God forbid anyone practicing Real Medicine tries to go the OSS route, medicine is too complicated for something like that.

$50M? Pfft. The regional health service provider over here has spent close to a billion € migrating to Epic over the past decade. The feedback has been so devastating they're apparently now considering starting over from scratch. Love seeing the consultants lighting my tax money on fire like that.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#93
post #47

Most of these vulnerabilities could have been discovered much earlier had the same security researchers pointed a SAST tool at the codebase. I wrote an OSS PHP SAST tool 6 years ago, but it's suffered from industry neglect — most people only care about security after an incident, and PHP has enough magical behaviour that any tool needs to be tuned to how specific repositories behave. I agree there's a big opportunity…

Where can I learn more about SAST, and do you have a link to your tool? I stood up a Dokuwiki instance recently and had Qwen look through the codebase, and it didn't find anything critical. It identified "fragile patterns", though.

It's Psalm — see the section on security analysis here: https://psalm.dev/docs/security_analysis/

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#94

Earlier quoted context omitted.

Having AI tools do the review against the checklist would probably prevent the problems. However, it would probably be substantially inferior as a teaching tool for your team. The exercise of having reviewers hunt the checklisted vulnerabilities for themselves is what develops the mental muscles needed to understand the vulnerabilities in depth and avoid them when designing and writing future code. But, yes, I'd augm…

Suppose we still need humans to be writing code and caring about this stuff for the foreseeable future, so we need people to continue learning about the ways things can go wrong. For something like injection, you still ideally have a lint rule that says "don't concatenate things that look like SQL/HTML/etc. Use the correct macros for string interpolation". What does it actually teach for a reviewer to tell you that?…

Two issues here. First, teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose, in general, and thus be less likely to "ask the robot to patiently explain" problems until they understand the problems' root causes and update their mental models to prevent those problems.

Second, to use your example, the ChatGPT response you provided does a crappy job of explaining the root cause of problem: Namely, that every string is drawn from some underlying language that gives the string its meaning, and therefore when strings of different languages are combined, the result can cause a string drawn from one language to be interepreted as if it were drawn from another and, consequently, be given an unintended meaning.

So, if the idea is that smart teams can not only delegate the catching of problems but also the explanation of those problems to ChatGPT -- presumably because it is a better teacher than the senior engineers who actually understand the salient concepts -- I'd say AI ain't there yet.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#95
post #37

Earlier quoted context omitted.

Isn't this something SonarQube catches?

Yes. Isn't this something code review catches? :)

Sometimes, but not nearly as reliably as a static analyzer. But I'm assuming the unstated point you are sarcastically implying is "you don't need SonarQube" - maybe you're trying to say something else.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#96
post #78

Earlier quoted context omitted.

There are Static code analyzers which already would have detected that. And these were also automatic. Looks very likely that the team didn’t give a damn about top basic security and good practices. Like a house made of paper wouldn’t be an example of the insecurity of the construction industry.

Which static code analyzers do you recommend?

SonarQube is extremely common, but I'm sure there are many.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#98
post #3

No one knows how many vulnerabilities there are in closed source medical record software - because we can't check. There are _probably_ loads though, because that medical software is super terrible in every way that we _can_ check.

Or voting machines.

I wasn't aware that there were any public, commonly-used voting machines that we could check.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#99
post #2

"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…

>even really strong development teams still occasionally let bugs like this slip through

agreed, though I think you'd be hard-pressed to find anyone who uses healthcare-related software professionally who thinks any "really strong development team" was involved in its creation.

Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software

#100
post #73

Earlier quoted context omitted.

> Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. Seems like code review against a checklist of the most common vulnerabilities would have prevented these problems. So I guess there are two takeaways here: First, AI scanners are useful for catching security probl…

I think it shows exactly the opposite of the second. Even with the availability of checklists, and instructions to use them, people won't and don't actually use them consistently. 'With enough eyes, all bugs are shallow' and AI is an automatable eye that looks at things we can tell nobody has seriously looked at before. It's not a panacea, there will be lots of false positives, but there's value there that we clearly…

> See also: modern practices and sanitizers and tools and test frameworks to avoid writing memory errors in C, and the reality that we keep writing memory errors in C.

I think there's a difference in how trivial some of these things are to detect and how difficult others are. IDOR and SQLi aren't nearly as complex as C unsafety is.

Post reply on HN