[Chicken-users] [SECURITY] Inconsistent NUL byte handling
Hello Chicken users, Recently a vulnerability was found in some of Chicken's string processing code. As you know, NUL bytes are representable by Scheme strings, but not by C strings (where they are treated as terminators). This mismatch is properly handled by the FFI by throwing an exception when it finds embedded NUL bytes. Most of Chicken's internal code either uses the FFI or the underlying procedure that performs this check. However, in a few places this didn't happen. Notably the standard R5RS file procedures do not check for embedded NUL bytes. The list of affected procedures is as follows: - From unit posix: * process * process-execute * process-run * get-environment-variable (via C_get_environment_variable) - From unit library: * system (via C_execute_shell_command) * ##sys#message (via C_message) * string-number (via C_a_i_string_to_number) * ##sys#open-file-port (via C_open_file_port) and its clients: - open-input-file - open-output-file - call-with-input-file and its clients: - include - load - read-file (from extras) - read-all (from utils) - with-input-from-file - call-with-output-file and its clients: - create-temporary-file (from files) - with-output-to-file If you are using any of these procedures or the underlying C procedures, you might be vulnerable to a poisoned NUL byte attack. The fix is to either check manually in your program for embedded NUL bytes or apply git revision d9f2ad87b42f. This patch is also available in 4.8.0rc3 (but not rc2!) and will make it into the final 4.8.0 release. Finally, ##sys#halt is affected too, but only under Windows in GUI mode. This is currently unpatched. ##sys#halt will halt the process, displaying a message, so abuse of this procedure is extremely unlikely (it can result in truncated error messages). After the release, we will try to come up with a more complete approach to fixing these problems. Kind regards, The Chicken Team References -- http://www.phrack.org/issues.html?issue=55id=7#article http://www.ouah.org/nullbyte.html ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] New egg: dummy-user
Hello, all-- Well, here's my first egg. It wasn't going to be: I am developing an egg that provides a framework for interactive command-line programs. But I realized in order to test that egg, I'd need a way to simulate user input. Hence ... dummy-user! The egg is BSD-licensed, and should be quite simple to use (its capabilities are also simple). For anyone who is interested, I've documented it on the wiki: http://wiki.call-cc.org/eggref/4/dummy-user And if the powers that be would be so kind as to add my little egg to the list ... the code is on GitHub; here's the location of the release info file. https://raw.github.com/mgushee/dummy-user/master/dummy-user.release-info Thanks, everybody! -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] New egg: dummy-user
On Mon, Sep 03, 2012 at 11:20:15AM -0600, Matt Gushee wrote: Hello, all-- Hi Matt! Well, here's my first egg. It wasn't going to be: I am developing an egg that provides a framework for interactive command-line programs. But I realized in order to test that egg, I'd need a way to simulate user input. Hence ... dummy-user! Cool :) And if the powers that be would be so kind as to add my little egg to the list ... the code is on GitHub; here's the location of the release info file. I've added it. This means it should appear for download by chicken-install within the hour, I think. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] New egg: dummy-user
Hi Matt, On Mon, 3 Sep 2012 11:20:15 -0600 Matt Gushee m...@gushee.net wrote: Well, here's my first egg. It wasn't going to be: I am developing an egg that provides a framework for interactive command-line programs. But I realized in order to test that egg, I'd need a way to simulate user input. Hence ... dummy-user! The egg is BSD-licensed, and should be quite simple to use (its capabilities are also simple). For anyone who is interested, I've documented it on the wiki: http://wiki.call-cc.org/eggref/4/dummy-user And if the powers that be would be so kind as to add my little egg to the list ... the code is on GitHub; here's the location of the release info file. https://raw.github.com/mgushee/dummy-user/master/dummy-user.release-info Very nice. Thanks for making your code available. I noticed that the egg documentation doesn't contain a link to the sources location. Usually egg authors add something like a Repository section, so people can easily see where the source code is. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] New egg: dummy-user
On Mon, Sep 3, 2012 at 11:29 AM, Mario Domenech Goulart mario.goul...@gmail.com wrote: Very nice. Thanks for making your code available. You're welcome. I noticed that the egg documentation doesn't contain a link to the sources location. Usually egg authors add something like a Repository section, so people can easily see where the source code is. Oh, okay. I'll take care of that. -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Modeling a state machine
Hello, all-- I have a question that is not Chicken-specific, or even scheme-specific, but since it relates to a project I'm developing in Chicken Scheme, I hope you will humor me. I have been working on a framework for interactive command-line programs. I have an initial version that works for my needs; I was thinking of releasing my work as an egg, but I now believe that the library is rather poorly designed. So I'm going to use it in its present form, but if I am going to release it to the public, I need to fundamentally redesign it. The basic problem is that there is a lot of special-case code to deal with some complex data types that are important for me, and possibly to others. Thus I think the code will be a nightmare to maintain; furthermore, it occurs to me that what this library provides is (or can be seen as) a form of finite state machine. Yet that model is not clearly expressed in the current code--I'd say there is no coherent architectural principle at all. To be more specific, here's a very simple example of what you can do with the current version: (use text-menu) (interact (steps (first: (make-step 'first-name)) (second: (make-step 'last-name)) (third: (make-step 'phone required: #f)) (fourth: (make-step 'email required: #f))) looping: #t) (get-all-data) This is working code. If you run it, it presents prompts like first-name: , and record the input ... and since 'looping' is true, when you finish one the series once, you have a choice to start over or quit ... and afterwards a call to (get-all-data) retrieves all the data that was collected. Now, that 'make-step' function can be customized in various ways via keyword arguments ... you can specify a customized prompt, a default value, validators, actions to perform based on the input, and a few other things. So you can imagine already that there is a lot of internal complexity. There are also several specialized 'make-step' functions for handling specialized data types, and a couple of those are quite complex indeed. The general procedure for handling each prompt-and-input cycle looks like this (in pseudocode): show prompt input = get-input valid = validate input if not valid - handle error perform action on input record input choose next step But: there are these important exceptions I mentioned, which necessitate a process like this: show prompt raw input = get-input - input = preprocess input valid = validate input if not valid - handle error perform action on input record input choose next step Now, I see two big trouble spots here: 1) the input and output of the preprocessing step necessitates modifications to some of the other steps, because although much of the data is just strings, there are other types that are more usable as lists or more complex structured types; and 2) the invalid input handling is special case code; I imagine in a properly architected state machine it would just be another prompt-and-input cycle. I'll go into a bit more detail about the preprocessing problem below. But first, let me say it seems to me there are 3 basic approaches to this situation: a) provide specialized procedures for specialized data types; not too different from the current design; b) allow preprocessing functions to return arbitrary data types, and trust that application developers are smart enough to provide appropriate functions to work together with those preprocessors; or c) standardize all data -- i.e. everything is handled internally as a string, or as a list, etc. Here are the two main examples of specialized data that are messing me up: DATES - I want to be able to handle dates in a flexible and user-friendly manner. Specifically: * The user should be able to enter dates in any of several common formats: 2012-09-03, 9/3/2012, Sept. 3, 2012, etc. (actually only ISO format and US-style MM/dd/YY[YY] styles are currently supported. * It is possible to enter abbreviated dates, e.g. MM/dd/YY, or MM-dd, and have the date default to the current year, month, etc. * You can specify a range of allowed years (default: 1-3000 AD) * The preprocessor extracts the year, month, and day using irregex submatches, and returns a list of integers: '(Y M D). * The validator checks the '(Y M D) using integer arithmetic, so that, for example, years outside the allowed range are rejected, dates 31, or 30, or 29, or 28 are rejected, depending on the month. ENUMS - These are basically predefined (optionally extensible) lists of items for the user to choose from. So a [simplified] enum might look like: '((copy . Copy a file) (move . Move a file) (delete . Delete a file)) This gives rise to a display something like this: 1) Copy a file 2) Move a file 3) Delete a file And if the user enters 2, the preprocessor extracts from the enum the symbol for Item #2, which is
