Thread

Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived

487 points · 270 comments · boredjohnny

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. HoldOnAMinute · 1790117534 · focus · HN ↗
  Maybe someone can put the core FoxPro ideas on top of SQLite
  1. EvanAnderson · 1790118565 · focus · HN ↗
    If it isn't client / server architecture there's no privilege separation using SQLite either. The storage format isn't the concern. Rather, the concern is it all runs in the same OS security context.
    fodkodrasz · 1790145497 · focus · HN ↗
    But it is a feature... I mean Excel also runs there...
    cm2187 · 1790151262 · focus · HN ↗
    Exactly, or an access database. This is to enable end users who live in a fully locked down environment (enterprise setup) and can't install anything to use database like features without having to wait 6 months for IT to lift a finger.
    But if it starts being a system of records / authoritative system, there needs to be a plan to decommission it.
2. EvanAnderson · 1790118506 · focus · HN ↗
  One of the Ohio Secretary of State's "certified" (wrong terminology, but you get the idea) voter registration databases used by various county Boards of Elections is written in VFP. The software maintains the list of voters, their addresses, and scans of signatures.
  Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
  Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
  I hang my head.
  1. marcus9999 · 1790129991 · focus · HN ↗
    seen this exact pattern in small business FoxPro setups too, DBFs on a share are one dropped SMB connection away from a corrupted index. if you're stuck maintaining something like this the least bad move is nightly copies of the whole folder to a second box, and actually opening that copy in the app now and then instead of just checking that the file sizes match.
    monster_truck · 1790183230 · focus · HN ↗
    This is an _excellent_ example of what anyone who has been professionally responsible for backups means when they say "it's not a backup until you've restored from it, booted into it, opened the app, and accessed the data"
    There's still so much software out there that is an absolute lynchpin to a business that will never have the kind of durability/compatability many take for granted. The only thing that has changed in the past 2 decades is the operating system running the VM. In 2026 they are still yelling across the office or exchanging phone calls when one has finished and signed out so that the other can sign in and pull the updates.
    It often isn't taken seriously or is written off because it's a "small business", but those 2-8 people run a book of business that clears this comment thread's lifetime earnings annually.
  2. pbhjpbhj · 1790148810 · focus · HN ↗
    Sounds like it works as designed.
3. boredjohnny · 1790118595 · focus · HN ↗
  Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?
  1. mikestew · 1790122457 · focus · HN ↗
    Feel free to quote me, contact info in profile if needed.
    EDIT: sorry, I originally just skimmed your comment. I was unclear in my original comment: the files can be accessed and “hacked” from the file system with a text editor. (And a bunch of deleted stuff because I misread your comment.)
  2. [deleted] · 1790123812 · focus · HN ↗
    [deleted]
4. 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.
    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.
    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.
    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?
    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.
    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?
    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.
    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 :-/
    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.
    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.
    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”.
    dspillett · 1790126549 · focus · HN ↗
    > Well, I had to call it something.
    A significant weakness?
    A serious limitation for modern uses / in modern environments?
    kennywinker · 1790131138 · focus · HN ↗
    A massive footgun? :)
    cestith · 1790197635 · focus · HN ↗
    Obsolete security model?
    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.
5. chasil · 1790125422 · focus · HN ↗
  Many of the complaints you make apply to SQLite as well?
  I don't know if dBASE variants support bind variables. That isolation is really required to avoid the "Bobby Tables" effect.
  <a href="https://bobby-tables.com/" rel="nofollow">https://bobby-tables.com/
  I'd prefer to see the dBASE language adapted to run on SQLite files, as they are a far more profound standard.
  1. Arainach · 1790139242 · focus · HN ↗
    OP never mentioned SQLite. Most SQL products support proper ACLs.
    chasil · 1790144997 · focus · HN ↗
    I feel good about you, and that you are a good person, through and through. We don't say that enough here.
    The permissions exploits on SQLite and dBASE are identical, sad to say.
    You're a good guy. I respect you.
    vidarh · 1790148582 · focus · HN ↗
    And that would be relevant if someone use sqlite as the default database backend for multiuser applications with stored procedures.
    That's the problem here: Systems built on sharing the database over a networked filesystem, where one user can not just modify all the data, but can also execute code on all users machines.
6. ransom1538 · 1790127685 · focus · HN ↗
  True. When someone on the internet sends me a vfp file... i just open it in my IE6.0 no cares given.
7. SigmundA · 1790130836 · focus · HN ↗
  I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.
  When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.
  Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.
  Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.
8. mamcx · 1790131244 · focus · HN ↗
  > Here’s my problem with reviving FoxPro in any form
  And then it moves to the orthogonal problem:
  > SQL DB
  (that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)
  And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)
  ---
  As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:
  Imagine you say to a C developer:
  "You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"
  Or even better, the user!:
  "You should not own your own filesystem!"
  The DB is like the filesystem, but not that dumb!
  The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.
  Or is just a embedded device.
  WHAT DECIDE THE SECURITY MODEl?
  The kind of storage?
  Nope!
  Is the deployment and use case.
  Similarly, what decide the security of a database?, the fact is a "database"?
  No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.
  In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.
  ----
  P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek
  P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!
9. j45 · 1790137018 · focus · HN ↗
  Could the security hole not be closed up?
  Maybe there's a way to run them more securely with a wrapper.
  It does make sense to try and move to a sql db of some type, and my immediate thought is if something like Postgres, with a plugin or extension or two couldn't simulate enough of Foxpro.
  That, or rewriting large parts of the DB engine seem readily much more possible now with LLM driven development.
10. merb · 1790137502 · focus · HN ↗
  Actually you can use foxpro with mssql and ole, you could than even add row level security for even more security
11. bluebxrry · 1790154748 · focus · HN ↗
  > FoxPro just executes what it finds in there.
  Perfect. I'm looking for a program that executes everything it reads. You've tracked a 20-year-old security bug for FoxPro? That's gnarly. What if, instead of reviving FoxPro, we summon a new type of DOS with no security model to begin with? FoxPro was always better that way.
  Hear me out. So, you have your regular computer on your desk, right? I call that the REAL SECURITY computer for REAL WORK: You know, your typical choice of Windows 11, Apple, or Linux. The biggest names in security. The names we trust. Real work. Real computers. Real security.
  Next to it sits FoxPro, running new DOS on a separate computer with no security model at all.
  Here's the ergonomics. You press your hands against your desk and push your office chair off like a boat, gliding away from the SECURE COMPUTER in the REAL WORLD toward FoxPro. FoxPro reads everything and executes with religious zeal.
  - written from my treadmill. edit: fix typos
12. KenPainter · 1790169741 · focus · HN ↗
  The largest VFP project I worked on used MS SQL Server.
  Foxpro's local DB handling was amazing at pulling down tables, doing complex bulk operations, and pushing the changes. Data transfer was fast, coding ergonomics were great. On top of the extremely low-cost UI creation, it was a no-brainer.
  But expectations were changing, everybody wanted to run it everywhere. Citrix bought some time, but the writing was on the wall.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.