I'm trying to locate the code that is responsible for changing the user and/or group id of the process when a setuid binary is exec'ed.
This is implemented in fs/exec.c, in prepare_binprm():
/* Set-uid? */
if (mode & S_ISUID) {
bprm->per_clear |= PER_CLEAR_ON_SETID;
bprm->cred->euid = inode->i_uid;
}
(You just have to know what to search for.)
Related
I am looking for a way to bypass a limit that is implemented the same way as the following
kexec_load_disabled:
{
.procname = "kexec_load_disabled",
.data = &kexec_load_disabled,
.maxlen = sizeof(int),
.mode = 0644,
/* only handle a transition from default "0" to "1" */
.proc_handler = proc_dointvec_minmax,
.extra1 = &one,
.extra2 = &one,
},
I have root access and I can load kernel modules aswell. I can use /proc/kallsymsto find the address of proc_dointvec_minmax, so I suppose I can somehow manage to write a kernel module that when loaded is able to overwrite the function so it allows going back to 0 again, then set the value to 0 and restore the original instructions? I assume I need to reconfigure the MMU first to allow writes to the kernel instructions? Or can I somehow add a breakpoint in proc_dointvec_minmax so that when it's hit I grab the arguments and modify those? Once I have a starting point I should be able to continue on my own, but right now I am not sure about what approach to choose/what the easiest way to solve it would be.
My application has a number of modules that each require some variables to be stored in off-chip non-volatile memory. To make the reading and writing of these easier, I'm trying to collect them together into a contiguous region of RAM, to that the NVM driver can address a single block of memory when communicating with the NVM device.
To achieve this, I have created a custom linker script containing the following section definition.
.nvm_fram :
{
/* Include the "nvm_header" input section first. */
*(.nvm_header)
/* Include all other input sections prefixed with "nvm_" from all modules. */
*(.nvm_*)
/* Allocate a 16 bit variable at the end of the section to hold the CRC. */
. = ALIGN(2);
_gld_NvmFramCrc = .;
LONG(0);
} > data
_GLD_NVM_FRAM_SIZE = SIZEOF(.nvm_fram);
The data region is defined in the MEMORY section using the standard definition provided by Microchip for the target device.
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0xD000
One example of a C source file which attempts to place its variables in this section is the NVM driver itself. The driver saves a short header structure at teh beginning of the NVM section so that it can verify the content of the NVM device before loading it into RAM. No linker error reported for this variable.
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header")));
Another module that has variables to store in the .nvm_fram section is the communications (CANopen) stack. This saves the Module ID and bitrate in NVM.
// Locate LSS Slave configuration in the non-volatile RAM section.
LSS_slave_config_t _slaveConfig __attribute__((section(".nvm_canopen"))) =
{ .BitRate = DEFAULT_BITRATE, .ModuleId = DEFAULT_MODULEID };
Everything compiles nicely, but when the linker runs, the following error stops the build.
elf-ld.exe: Link Error: attributes for input section '.nvm_canopen' conflict with
output section '.nvm_fram'
It's important that the variables can be initialised with values by the crt startup, as shown by the _slaveConfig declaration above, in case the NVM driver cannot load them from the NVM device (it's blank, or the software version has changed, etc.). Is this what's causing the attributes mismatch?
There are several questions here and on the Microchip forums, which relate to accessing symbols that are defined in the linker script from C. Most of these concern values in the program Flash memory and how to access them from C; I know how to do this. There is a similar question, but this doesn't appear to address the attributes issue, and is a little confusing due to being specific to a linker for a different target processor.
I've read the Microchip linker manual and various GCC linker documents online, but can't find the relevant sections because I don't really understand what the error means and how it relates to my code. What are the 'input and output section attributes', where are they specified in my code, and how do I get them to match eachother?
The problem is due to the _nvmHeader variable not having an initial value assigned to it in the C source, but the _slaveConfig variable does.
This results in the linker deducing that the .nvm_fram output section is uninitialised (nbss) from the .nvm_header input section attributes. So, when it enconters initialised data in the .nvm_canopen input section from the _slaveConfig variable, there is a mismatch in the input section attributes: .nvm_fram is for uninitialised data, but .nvm_canopen contains initialised data.
The solution is to ensure that all variables that are to be placed in the .nvm_fram output section are given initial values in the C source.
// Type used to hold metadata for the content of the NVM.
typedef struct
{
void* NvmBase; // The original RAM address.
uint16_t NvmSize; // The original NVM section size.
} nvm_header_t;
// The linker supplies the gld_NVM_FRAM_SIZE symbol as a 'number'.
// This is represented as the address of an array of unspecified
// length, so that it cannot be implicitly dereferenced, and cast
// to the correct type when used.
extern char GLD_NVM_FRAM_SIZE[];
// The following defines are used to convert linker symbols into values that
// can be used to initialise the _nvmHeader structure below.
#define NVM_FRAM_BASE ((void*)&_nvmHeader)
#define NVM_FRAM_SIZE ((uint16_t)GLD_NVM_FRAM_SIZE)
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header"))) =
{
.NvmBase = NVM_FRAM_BASE, .NvmSize = NVM_FRAM_SIZE
};
The answer is therefore that the output section attributes may be determined partly by the memory region in which the section is to be located and also by the attributes of the first input section assigned to it. Initialised and uninitialised C variables have different input section attributes, and therefore cannot be located within the same output section.
In IDA Pro 6.1, I have a dll which has twenty calls to the "CreateFileA" and "CreateFileW" function APIs.
I would like to specify breakpoints for all the CreateFileA/CreateFileW automatically.
I could do it manually for all the xrefs, but that is tedious.
Is there a way to specify a breakpoint directly for the CreateFileA/CreateFileW call?
Thanks a lot :)
You could set a break point at the first instruction of both CreateFile, or you could whip something up with IDAPython to create the breakpoints.
Iterate over all the instructions/calls and look for calls to the appropriate function.
add_bpt() I believe is the call,
Here's a script I wrote up to accomplish what you want. It sets soft-breakpoints at the locations that call your specified functions.
// Script used to set a breakpoint at the callsite
// of the specified function using cross-references.
#include <idc.idc>
static SetBreakpoint(location)
{
// Sets a breakpoint to be activated when
// the debugger runs over the address.
AddBptEx(location, 0, BPT_SOFT);
}
static CrossReferenceSource(source)
{
// Find the linear address of the source
// location to start xref'ing from.
auto sourcefn = LocByName(source);
auto iterfn = DfirstB(sourcefn);
if (sourcefn != BADADDR && iterfn != BADADDR)
{
do
{
Message("Setting breakpoint # 0x%08x\n", iterfn);
SetBreakpoint(iterfn);
iterfn = DnextB(sourcefn, iterfn);
} while(iterfn != BADADDR);
}
}
static main()
{
auto source = "FunctionName";
Message("--- Setting breakpoints at cross-reference ---\n");
CrossReferenceSource(source);
Message("--- Finished settings breakpoints --\n");
}
Replace "FunctionName" with the name of your function and run it within IDA's 'Execute Script' window available through File > Script command
A known limitation is that it won't recognize indirect cross-references (e.g. calls using the registers).
If CreateFileA/W are all imports (ie, externs defined in an .idata section), can you not just select the symbol in question and hit F2 (add breakpoint)? The Breakpoint settings dialog that comes up allows you to specify the Hardware breakpoint mode, which in this case we would want to limit to Read (since the symbol's value would be written to at startup when imports are resolved), which should only happen in 'call ds:CreateFileA' instances.
Some breakpoint notes from the IDA Help:
It is impossible to create more than 4 hardware breakpoints
Please note that hardware breakpoints occur AFTER the instruction execution while software breakpoints occur BEFORE the instruction.
As far as I know and according with kornman00 "CreateFile" is imported from a dll. In fact, it is imported directly from Kernel32.dll, You can take a look here if you are not sure how it works.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Therefore, In order to do what you are looking for, the best approach is going directly to it, set the breakpoint in kernel32.CreateFileA or kernel32.CreateFileW. The differences are just if the app use Ansichar or Widechar.
Obviously in order to do that, you need to start the debug process because kernel32 must be load for your app before you will be able to set a break-point there.
If you are getting confuse my advice is "load the binary in a simpler debugger" and try to figure out what we explained you before
I am reading the Linux kernel code for copy_fom_user, which is architecture dependent and I focus on x86 architectures.
But I got two pieces of implementation for it.
One is here (in arch/x86/lib/usercopy_32.c), while the other is here (in include/asm-generic/uaccess.h).
Which one will be finally compiled into the kernel. I guess the former is the real one, but I am not sure. What is more strange is that the former has the function name _copy_from_user instead of copy_from_user
I always have this kind of confusions when reading the kernel code. For example, due to the conditional compiling, the same function may have multiple implementation and I cannot determine which one will be used in general. Is there any tool that, given a complied kernel and a function of interest, tells you the corresponding binary code, so that you can disassemble it? Or it would be even better if it can tell you the source code that the binary code corresponds to.
Generally, if there is a module present in the architecture-specific subdirectory, that is the one being used. Otherwise, the generic one is it.
For the modules given, the .c is the correct one. Rarely is there any executable code in a .h. I have 2.6.27.8's uaccess.h handy:
#ifndef _ASM_GENERIC_UACCESS_H_
#define _ASM_GENERIC_UACCESS_H_
/*
* This macro should be used instead of __get_user() when accessing
* values at locations that are not known to be aligned.
*/
#define __get_user_unaligned(x, ptr) \
({ \
__typeof__ (*(ptr)) __x; \
__copy_from_user(&__x, (ptr), sizeof(*(ptr))) ? -EFAULT : 0; \
(x) = __x; \
})
/*
* This macro should be used instead of __put_user() when accessing
* values at locations that are not known to be aligned.
*/
#define __put_user_unaligned(x, ptr) \
({ \
__typeof__ (*(ptr)) __x = (x); \
__copy_to_user((ptr), &__x, sizeof(*(ptr))) ? -EFAULT : 0; \
})
#endif /* _ASM_GENERIC_UACCESS_H */
Look at that carefully. These are macro wrappers to call the underlying __copy_from_user() and __copy_to_user() functions, which are implemented differently on each architecture.
What's the way to get default volume on Mac 64-bit?
I have a code like that:
GetVolParmsInfoBuffer buf_64 = { 0 };
status = FSGetVolumeParms(vol_ref, // use default volume
&buf_64, // write
req_count);
The problem is that I can't pass 0 in vol_ref. On Mac 32-bit I could write:
GetVolParmsInfoBuffer buf_32 = { 0 };
HParamBlockRec pb;
pb.ioParam.ioCompletion = NULL; // not doing async I/O
pb.ioParam.ioNamePtr = NULL; // we don't use path name
pb.ioParam.ioVRefNum = 0; // use default volume
pb.ioParam.ioBuffer = reinterpret_cast(&buf_32); // write data here
pb.ioParam.ioReqCount = req_count;
OSErr err = PBHGetVolParmsSync(&pb);
ASSERT_EQ(err, noErr);
Thanks in advance,
- Oleksii
In the File Manager docs, you'll notice a function group titled “Manipulating the Default Volume”. All of those functions are deprecated.
If you search Google for the functions therein, particularly HSetVol, you'll find this mailing list post by Eric Schlegel, which says HSetVol had the effect of setting the current working directory (expressed as a volume/directory pair) on Mac OS. He also says that it doesn't work on Mac OS X: It should work on File Manager functions, but does not set the working directory used for resolving relative paths in other APIs (e.g., open and fopen) like it did on Mac OS.
Moreover, those functions are not available in 64-bit Mac OS X. So the answer is: You don't, because there is no default volume.
The old meaning of it was analogous to the current working directory, so you can do the same thing by getting the CWD and resolving that path to an FSRef. However, for a Mac OS X application (particularly one that doesn't set the CWD by any means, as most don't), this is not terribly useful: The default CWD for an application is /, the root directory of the boot volume. On the other hand, if you run your executable directly or under Xcode's Debugger, its CWD will not be /, which means it could be some other volume—most probably, the one with your Home folder on it.
You should refer to the boot volume (or whatever volume you're interested in) specifically, not attempt to get or simulate getting the default (current working) directory.
For the boot volume, you might try kOnSystemDisk, which is one of the constants in the Folder Manager. If that doesn't work, use Folder Manager's FSFindFolder function to retrieve the System folder, then use File Manager's FSGetVolumeInfo function to get what volume it's on.
Well. I don't really know what "default volume" is. All I know is that Carbon manual (File Manager) says:
ioVRefNum
A volume reference number, 0 for the default volume, or a drive number.
Well, I seem to find the answer for my question.
FSVolumeInfoParam vol_info = { 0 };
vol_info.ioVRefNum = kFSInvalidVolumeRefNum; // will obtain it
vol_info.volumeIndex = 1; // XXX: is it the default volume as well?
vol_info.whichInfo = kFSVolInfoNone; // don't pass volume info
err = PBGetVolumeInfoSync(&vol_info);
The only thing I'm not sure of is if the 1st volume is the default one...
P.S. I guess the problem is that I don't quite understand what "default volume" really is ;-)