Thread

1. mikestew · 1790117337 · focus · HN ↗

   Here’s my problem with reviving FoxPro in any form: there’s a huge security hole in the Database Container (DBC) design. For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a “memo” field. Do you see where this is going? With a little technical knowledge, one can modify that INSERT trigger to whatever you like. EDIT: as the DB is just files in the file system, modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there.

   My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.

   Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.

   1. userbinator · 1790122992 · focus · HN ↗

      there is no permissions scheme

      If you already have full access by design, then there's no "huge security hole" either.

      1. EvanAnderson · 1790123702 · focus · HN ↗

         Exactly. It's not a security hole. It's just the architecture of the program.

         It seems like many people have a hard time understanding this, including developers.

         Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.

         1. shermantanktop · 1790131812 · focus · HN ↗

            You’re saying it’s not a 2 tier client/server app, it’s a one tier app with no intermediate API to define or enforce permissions. Fine.

            But the filesystem access to read/write the db files creates a path to bypass half of that application.

            Does the application checksum the db file and have any resistance to filesystem tampering? That'd be trivial to beat, I’m sure, but it’d be something.

            1. aforwardslash · 1790135212 · focus · HN ↗

               Well, on a different note, if you have a scripted language application, you typically can edit files and bypass whatever you want on the application. In fact, I'd bet most modern software isn't signed; and even if it is, sometimes the libraries that get compiled in into that signed binary... aren't.

               I can change the behaviour of many/most applications by just having read/write access to files; Can you give me examples of mainstream applications that are resistant to filesystem tampering when eg.you have install access? Maybe I'm missing something.

            2. lelanthran · 1790148102 · focus · HN ↗

               > But the filesystem access to read/write the db files creates a path to bypass half of that application.

               Is there any local/native application for which this is not true?

               1. shermantanktop · 1790174895 · focus · HN ↗

                  With a permissions system that’s meant to enforce security? I hope not.

                  I’m not a FoxPro user and so maybe these are single-user/single-host installs, where the user can only destroy their own data, and permissions are a pretend feature. In which case, carry on.

                  1. 306bobby · 1790255563 · focus · HN ↗

                     Can't you just use filesystem permissions? Like, FoxPro under its own user and it's database owned and accessible by FoxPro user only?

                     1. EvanAnderson · 1790263545 · focus · HN ↗

                        Sure. The user would need to logon as the FoxPro user to use the application. At that point, having the FoxPro user credentials, the user can manipulate the FoxPro data files directly without using the application.

                        The rub here is that FoxPro is an in-process database engine and accesses its data files with the security context of the user running the application. It doesn't have separation between the database engine and the UI like a client/server database would. Think of it like SQLite or BerkeleyDB.

                        Architecturally users who use the application need full read/write access to all the data files for FoxPro to work.

                  2. lelanthran · 1790255616 · focus · HN ↗

                     > With a permissions system that’s meant to enforce security? I hope not.

                     There's different needs for a permissions system.

                     You're thinking of it as "lock to the main entrance of a maximum security prison". Think of it more as a lock on a bedroom door: it's not there to withstand a SWAT assault, it's there to keep people from accidentally walking in.

                     All local applications (which were all applications in the era we are talking about) with permissions were sold to companies on the understanding that there was no real security.

                     Hell, even the networked products at the time had no real security :-/

         2. Towaway69 · 1790147240 · focus · HN ↗

            Further along those lines, it was a different world when the code was created.

            Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.

            And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.

            1. antonvs · 1790161512 · focus · HN ↗

               It had absolutely nothing to do with trust. People still worried about the security of their databases. Businesses understood perfectly well that their electronic records were just as sensitive as their paper ones. But the server closet had a lock on the door, and no wire connecting it to a global network of mostly scammers. It was just as secure as the paper records.
            2. mikestew · 1790178784 · focus · HN ↗

               Trust was a thing back then.

               No, it wasn't. The reason I even raised this bug to begin with was not because of some nefarious $BAD_COUNTRY hacker getting yer dataz from far away, it's because you have to worry about your own users first. I'd guess that any consultant doing the kind of work FoxPro excelled at (LOB apps) has found some clever boy or girl who discovered they can poke at DBF files directly. Long before internet connectivity was common, one still had to worry about your own coworkers futzing things up.

      2. mikestew · 1790125079 · focus · HN ↗

         Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.

         1. dspillett · 1790126549 · focus · HN ↗

            > Well, I had to call it something.

            A significant weakness?

            A serious limitation for modern uses / in modern environments?

            1. kennywinker · 1790131138 · focus · HN ↗

               A massive footgun? :)
            2. cestith · 1790197635 · focus · HN ↗

               Obsolete security model?
         2. Shorel · 1790164382 · focus · HN ↗

            There's a category in the OWASP Top 6, called: Insecure Design.

            It is top 6 in their vulnerabilities ranking.

            This is definitely insecure design.

      3. alper · 1790167159 · focus · HN ↗

         This is entirely how FP is supposed to work. Don't like that, don't use it.

         It ships database files over the network and does that blazingly fast.

Unofficial Hacker News client; not affiliated with Y Combinator.